<div dir="ltr"><div dir="ltr">Hi Nicolas,</div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Chris, what is the purpose of fractional layouts?</div><div>It is to provide adaptive behavior to window resizing.</div></div></blockquote><div><br></div><div>Right.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>LayoutFrame enable having a mixture of fixed size widgets, variable size widgets with size proportional to window extent, or mixed case.</div><div>Patching the layout with absolute offsets, is a big mistake, because the layout then misbehave when window is resized, especially when shrinked.</div></div></blockquote><div><br></div><div>It doesn't matter,  the feature is about animating the splitters to keep the display of information constantly optimized.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>The offsets are not proportional, and they are not meant to be, they are fixed width constraints!<br></div></div></blockquote><div><br></div><div>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.</div><div></div><div><br></div><div>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.</div><div><br></div><div>And, the feature is pretty much isolated off to the side, behind those two preferences, not hurting anyone.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Patching the offset also override the fixed width specification, which is another mistake: fixed size constraint information is lost. </div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div><br></div><div>What smart splitters do? They are introducing a new rule: size is proportional to contents.</div><div>It may express some constraints in term of absolute positioning/extent, that's not a problem.<br></div><div>What I deny is the fact that it would resolve those constraints by changing absolute offsets. </div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Smart splitters shall adapt the proportional layout of widgets, that's crystal clear.<br></div><div><br></div><div>The problem I exposed is not related to smart splitters, just to the way regular splitter (miss)-work.</div><div>We should first solve that, having a reasonable behavior and simple implementation, then we will come back to smart splitters.<br></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>Best,</div><div>  Chris</div></div></div>