[squeak-dev] MCSaveVersionDialog splitter broken

Chris Muller asqueaker at gmail.com
Thu Nov 21 05:29:10 UTC 2019

Hi Nicolas,

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.

It doesn't matter, the feature is about animating the splitters to keep the
display of information constantly optimized.

> The offsets are not proportional, and they are not meant to be, they are
> fixed width constraints!

Well, absolute offsets are used when simply dragging any splitter, right?
It's tied to the hand position.  That's probably the other problem you're
seeing now -- some rounding glitch when calculating the new proportion with
offset 0, after the drop.

Smart splitters is about realizing a finely-tuned IDE that meets certain
explicit user requirements.  It uses Proportional whenever the user
overrides with a manual drag, otherwise, the equivalent of "dragging
splitters" is all only what it ever does, constantly, in response to
content occlusion.

And, the feature is pretty much isolated off to the side, behind those two
preferences, not hurting anyone.

> 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.

I don't think the requirements demanded of smart-splitters can be met via
proportional calculations.  There's too much variability and feedback.  The
need for pixel-level refinements made it delicate and difficult to get
optimized.  Maybe SOME improvement could be found somewhere but, trust me,
messing with it will waste your time and drive you crazy.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191120/ad7d866b/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/ad7d866b/attachment-0001.gif>

More information about the Squeak-dev mailing list