Hi Marcel,
unfortunately it did not solve the problem for me, but just displace the
problem:
Open a MCPatchBrowser (with annotation panes preference enabled), click the
splitter
and you will see it drifting downward...

Le mer. 20 nov. 2019 à 16:22, Marcel Taeumel <marcel.taeumel at hpi.de> a
écrit :

> Hi, all.
>
> I just fixed this issue in Trunk (Morphic-mt.1590). Still, there is
> another, smaller, issue remaining:
>
>
>
> Best,
> Marcel
>
> Am 20.11.2019 09:43:23 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
> Hi Nicolas.
>
> > how long does it take to produce such animation?
>
> About 1-3 minutes if you know what to capture with Camtasia Studio on a
> Surface Pro 6 Laptop.
>
> Best,
> Marcel
>
> Am 20.11.2019 09:38:54 schrieb Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com>:
> Thanks Marcel!
> how long does it take to produce such animation?
>
> Chris, what is the purpose of fractional layouts?
> It is to provide adaptive behavior to window resizing.
> LayoutFrame enable having a mixture of fixed size widgets, variable size
> widgets with size proportional to window extent, or mixed case.
> Patching the layout with absolute offsets, is a big mistake, because the
> layout then misbehave when window is resized, especially when shrinked.
> The offsets are not proportional, and they are not meant to be, they are
> fixed width constraints!
> Patching the offset also override the fixed width specification, which is
> another mistake: fixed size constraint information is lost.
>
> What smart splitters do? They are introducing a new rule: size is
> proportional to contents.
> It may express some constraints in term of absolute positioning/extent,
> that's not a problem.
> What I deny is the fact that it would resolve those constraints by
> changing absolute offsets.
> Smart splitters shall adapt the proportional layout of widgets, that's
> crystal clear.
>
> The problem I exposed is not related to smart splitters, just to the way
> regular splitter (miss)-work.
> We should first solve that, having a reasonable behavior and simple
> implementation, then we will come back to smart splitters.
>
>
> Le mer. 20 nov. 2019 à 09:02, Marcel Taeumel <marcel.taeumel at hpi.de> a
> écrit :
>
>> This is the bug (smart splitters disabled, left mouse click):
>>
>> 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>
>> 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-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?
>>>
>>> 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/20191120/1196081e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.gif
Type: image/gif
Size: 791956 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191120/1196081e/attachment-0001.gif>