[squeak-dev] MCSaveVersionDialog splitter broken

Chris Muller asqueaker at gmail.com
Wed Nov 20 04:15:59 UTC 2019

Hi Nicolas,

I don't really understand the symptom you describe, but if you
yellow-clicked the splitter, then that would've invoked the manual
smart-splitter feature.

It takes care to follow certain principles which require absolute
positioning relative to other widgets.  For example, the desire to reduce
the number of scroll bars.  Another is to avoid stealing focus when
mouseOverForKeyboard focus is used.  These requirements require a duality
of proportional and absolute positioning control.  I made a video a while
ago which presents the feature and covers this point. [1]


[1] -- https://youtu.be/JPQrDMIpjis

On Sun, Nov 17, 2019 at 4:34 PM Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

> 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 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/20191119/6f3d1eec/attachment.html>

More information about the Squeak-dev mailing list