[squeak-dev] MCSaveVersionDialog splitter broken

Chris Muller asqueaker at gmail.com
Wed Nov 20 04:40:12 UTC 2019

On Mon, Nov 18, 2019 at 2:20 AM Marcel Taeumel <marcel.taeumel at hpi.de>

> 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-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>:
> 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/796ba9cc/attachment.html>

More information about the Squeak-dev mailing list