[squeak-dev] MCSaveVersionDialog splitter broken

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Sun Nov 17 22:34:03 UTC 2019


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> 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> 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> im
>> Auftrag von Nicolas Cellier <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/20191117/7bebf7f1/attachment-0001.html>


More information about the Squeak-dev mailing list