Does anyone know where FramingLayout originates from? Was it ported from another Smalltalk or another programming language, or is it original to Dolphin?

I'm trying to use it for laying out objects within a GdiplusDoubleBufferedView and having issues trying to extend its behavior, so I started formalizing it in Agda to better understand how it works. That got me curious about its history and whether there
are other applications that are more similar to my use case that I could use as examples.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

From the tiny bit I played with it a while ago, Apple's Auto Layout (in native Cocoa iOS/macOS applications) uses a similar but dramatically more powerful concept of constraints between the properties of views. On an implementation level it must be
significantly more complicated, and may work very differently, I don't know, but I recall coming to Dolphin and recognizing FramingLayout as at least somewhat similar (then being disappointed at the comparative lack of flexibility...). I think Auto
Layout would make for an excellent *aspirational* example, if perhaps not a practical target to fully emulate.

On Thursday, April 21, 2022 at 11:37:18 AM UTC-4, [email protected] wrote:

Does anyone know where FramingLayout originates from? Was it ported from another Smalltalk or another programming language, or is it original to Dolphin?

I'm trying to use it for laying out objects within a GdiplusDoubleBufferedView and having issues trying to extend its behavior, so I started formalizing it in Agda to better understand how it works. That got me curious about its history and whether

there are other applications that are more similar to my use case that I could use as examples.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I think Auto Layout would make for an excellent *aspirational* example, if perhaps not a practical target to fully emulate.

Yes, thank you! That's exactly what I needed. Because now it's obvious both what I want and why FramingLayout isn't it.

I was trying to extend FramingLayout to be able to express things like "the bottom frame of X is equal to the height of its content" and "the top frame of X is the bottom frame of Y" and not coming up with satisfying solutions with the existing
mechanisms. I did some research on Apple's Auto Layout and even though it's closed source there seems to be plenty of the underlying constraint solving algorithm, including an implementation in Squeak, which looks far more sane than what I was doing.

Now I'm left in that bittersweet state of having a clear idea of what I want and a whole new domain to learn in order to implement it. :}

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Because now it's obvious both what I want and why FramingLayout isn't it.

That was pretty much my reaction to FramingLayout, having already seen Auto Layout, yes :).

express things like "the bottom frame of X is equal to the height of its content"

I actually did this—there is already a "preferred extent" mechanism (see #usePreferredExtent, #preferredExtent, #calculateExtent:), which the simpler LayoutManagers "propagate" correctly (that is, a container's preferred extent is based on its contents)
. It isn't particularly difficult to add #preferredView{Top|Right|Bottom|Left} modes to FramingConstraints—analogous to #fixedViewWhatever but based on the preferredExtent. I'll have to see about contributing those changes at some point, along with
filling in some gaps in controls knowing how to calculate their preferredExtent. Note that FramingLayout itself I believe does *not* know how to calculate the preferred extent of its own container, so you can only have one level of it and have everything
calculate nicely.

"the top frame of X is the bottom frame of Y"

This is halfway possible as long as X and Y are immediate siblings (a View's collection of subviews is ordered, this is baked in to Win32)—there's a #fixedPrevious{Top|Right|Bottom|Left} constraint. However it can only propagate forwards, not backwards
(there is no #fixedNextWhatever), and more complex interrelationships are not possible. This is the point at which the problem outgrows FramingLayout's simple, single-pass algorithm, and a proper constraint solver like Auto Layout becomes necessary.

On Saturday, April 23, 2022 at 11:11:15 AM UTC-4, [email protected] wrote:

I think Auto Layout would make for an excellent *aspirational* example, if perhaps not a practical target to fully emulate.

Yes, thank you! That's exactly what I needed. Because now it's obvious both what I want and why FramingLayout isn't it.

I was trying to extend FramingLayout to be able to express things like "the bottom frame of X is equal to the height of its content" and "the top frame of X is the bottom frame of Y" and not coming up with satisfying solutions with the existing

mechanisms. I did some research on Apple's Auto Layout and even though it's closed source there seems to be plenty of the underlying constraint solving algorithm, including an implementation in Squeak, which looks far more sane than what I was doing.

Now I'm left in that bittersweet state of having a clear idea of what I want and a whole new domain to learn in order to implement it. :}

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, April 24, 2022 at 10:21:17 PM UTC+2, [email protected] wrote:

Because now it's obvious both what I want and why FramingLayout isn't it.

That was pretty much my reaction to FramingLayout, having already seen Auto Layout, yes :).

It was actually really really easy to integrate Auto Layout into my UI framework. I mean stupidly easy. It was basically filing in the Squeak implementation, making a few tweaks for Dolphin, then building up a layout DSL on top of the primitives. It only
took maybe an hour or two tops, and now I can say things like `title above: lastMessage; leftAlign: lastMessage; maxHeight: 30`. It's wonderful.

It's also infuriating to think that this solution has existed for literal decades and only Apple has bothered to use it. I mean, it's just rectangles on a 2D layout, it's really not that complicated. And certainly not 1/100th as complicated as HTML/CSS
make it seem.

The only thing you lose by ditching Dolphin's Layout system is the ability for a non-programmer to fiddle with things. But so what? That's basically the justification for Java / Smalltalk--, allowing non-programmers to fiddle with software. <disgust>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)