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 [mailto: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 [mailto: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




Best,
Marcel

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]>:
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 [mailto: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 [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 :-)

Best,
Christoph


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
 
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/0e780145/attachment.html>