[squeak-dev] MCSaveVersionDialog splitter broken

Marcel Taeumel marcel.taeumel at hpi.de
Wed Nov 20 08:02:30 UTC 2019

This is the bug (smart splitters disabled, left mouse click):

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


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]>:
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 [mailto:nicolas.cellier.aka.nice at gmail.com]> a écrit :

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 :-)


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
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/20191120/5ee2f7ef/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.gif
Type: image/gif
Size: 673683 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191120/5ee2f7ef/attachment-0001.gif>

More information about the Squeak-dev mailing list