[squeak-dev] MCSaveVersionDialog splitter broken

Nicola Mingotti nmingotti at gmail.com
Fri Nov 22 01:08:50 UTC 2019


Animated gif are a very good idea to show bugs in the mailing list ! 
I will keep it in mind.

bye
n.


> On Nov 20, 2019, at 12:02 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
> 
> This is the bug (smart splitters disabled, left mouse click):
> <image.gif>
> 
> Best,
> Marcel
>> Am 20.11.2019 05:40:59 schrieb Chris Muller <asqueaker at gmail.com>:
>> 
>> On Mon, Nov 18, 2019 at 2:20 AM Marcel Taeumel <marcel.taeumel at hpi.de <mailto:marcel.taeumel at hpi.de>> wrote:
>> Hi, there.
>> 
>> I cannot solve this issue at the moment.
>> 
>> Here is some history about (the rather recently added) #balanceOffsets:
>> 
>> http://forum.world.st/A-fix-for-ProportionalSplitterMorph-td5072182.html <http://forum.world.st/A-fix-for-ProportionalSplitterMorph-td5072182.html>
>> http://forum.world.st/A-fix-for-ProportionalSplitterMorph-take-2-td5072239.html <http://forum.world.st/A-fix-for-ProportionalSplitterMorph-take-2-td5072239.html>
>> 
>> > one could expect that a Morph bounds is obtained by applying its layoutFrame to its owner bounds
>> 
>> That's exactly what's happening. See:
>> 
>> Morph >> #doLayoutIn:
>> ProportionalLayout >> #layoutIn:
>> Morph >> #layoutProportionallyInBounds:(positioning:)
>> LayoutFrame >> layout:in:
>> 
>> > for example the grip morphs have a very strange idea of their own layoutFrame
>> 
>> Yes, grip morphs are quite hacky. Their relationship to SystemWindow and that window's label area required some unconventional overrides of #layoutProportionallyInBounds:(positioning:)
>> 
>> Anyway, that issue with #balanceOffsets: does not bleed into all these things. It is just confined within ProportionalSplitterMorph. I suppose. :-D
>> 
>> Yes, it appears I isolated balanceOffsets by the preference checks:
>> 
>>     (ProportionalSplitterMorph smartVerticalSplitters or: [ ProportionalSplitterMorph smartHorizontalSplitters ])
>> 
>> and in ProportionalSplitterMorph>>#stopStepping, it once again calls #balanceOffsets to put the state back to the manual-splitter scheme, as if the user had moved the bar themself.
>> 
>>  - Chris
>> 
>> 
>> 
>> 
>> Best,
>> Marcel
>> 
>>> Am 17.11.2019 23:34:24 schrieb Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com <mailto:nicolas.cellier.aka.nice at gmail.com>>:
>>> 
>>> Hi,
>>> what I see is completely against my opinion of the right thing.
>>> I gonna expose this opinion below.
>>> 
>>> #repositionBy: is trying to change the layoutFrame offsets of the splitter and its neighbour morphs...
>>> WHAT?
>>> 
>>> What are offsets for in the first place?
>>> They are used for reserving a fixed space, for example for a button to be one lineGrid high!
>>> A proportional splitter should not change the fixed space, it should rather consider it as a constraint.
>>> Instead, it should change the proportional space, that is the fraction part of layouts...
>>> As the name tells! A ProportionalSplitter SHALL change the proportional layout.
>>> 
>>> What is #balanceOffsets trying to do?
>>> It's trying to undo the mistakes that we performed in #repositionBy:by transforming the offset deltas into fraction deltas...
>>> Ouch, it's too late, I don't feel like this is a bright strategy!
>>> 
>>> By inspecting the Morphs, I see plenty of surprises... For example, one could expect that a Morph bounds is obtained by applying its layoutFrame to its owner bounds... Err, that ain't always the case, for example the grip morphs have a very strange idea of their own layoutFrame... So before I learn what the least surprise should be, it might take a bit of time... Otherwise, repairing one thing may break two others...
>>> If you have already gone thru this, share my opinion, and are ready to kill the problem you get my blessing ;)
>>> 
>>> Le dim. 17 nov. 2019 à 20:41, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com <mailto:nicolas.cellier.aka.nice at gmail.com>> a écrit :
>>> Bingo,
>>> if I inspect the ProportionalSpliiterMorph (thru halos), then evaluate in inspector:
>>> 
>>>     self setProperty: #fullDelta toValue: 0 at 0; balanceOffsets
>>> 
>>> I then get the undesired behavior...
>>> Thanks Christoph for the starting point
>>> 
>>> Le dim. 17 nov. 2019 à 19:20, Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de <mailto:Christoph.Thiede at student.hpi.uni-potsdam.de>> a écrit :
>>> Hi, I perceived a similar issue a year ago, I'm afraid it appears to have been forgotten ...
>>> 
>>> 
>>> 
>>> 
>>> I recently found a bug in the splitter class: Each time you mouseDown a splitter but not mouseMove it, it moves itself by delta=1. More concretely I could locate this during debugging in #balanceOffsets, where self layoutFrame leftFraction actually gets a larger value with every click. I was able to fix the problem by preventing every call to #balanceOffsets, but that doesn't seem to be the right solution. Since then, I haven't missed any splitter behavior, so I don't understand the point of this method.
>>> 
>>> Is there any reason why #fullDelta is set here?
>>> 
>>> 
>>> In every case, I think it could be a good idea to refactor #balanceOffsets in terms of readability :-)
>>> 
>>> Best,
>>> Christoph
>>> 
>>> Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org <mailto:squeak-dev-bounces at lists.squeakfoundation.org>> im Auftrag von Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com <mailto:nicolas.cellier.aka.nice at gmail.com>>
>>> Gesendet: Sonntag, 17. November 2019 19:11 Uhr
>>> An: The general-purpose Squeak developers list
>>> Betreff: [squeak-dev] MCSaveVersionDialog splitter broken
>>>  
>>> Hi,
>>> here is how to reproduce:
>>> 1. save any package
>>> 2. click on the horizontal splitter (below the list of changes)
>>> 3. the splitter goes up once at button down, and once at button up by about the vertical size of the Accept/Cancel buttons
>>> 
>>> I don't know where to start searching for it...
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191121/c32bcb23/attachment.html>


More information about the Squeak-dev mailing list