RectCut for dead simple UI layouts

Another approach I remember uses a pre-sized template and attaches sides to other sides (unlike to parent sides only). E.g. you have a form of width 1000, then you drop button A at (10,10)-(495,50), button B at (505,10)-(990,50), and then connect A.right to follow B.left instead of Form.left (which is default). B.left is then told to be proportional to Form.right, and B.right follows Form.right. When parent resizes, margins and the spacing between them (10) are naturally maintained from the fact that they were 10px apart at design time, i.e. the layout stores their initial coords for using in calculations. A minor issue is that proportional at 505 is not equidistant to proportional at 500 (a true middle of the spacing) at all times, but you just ignore that.

All the rules are of the form:

  A.side {follows|proportional} B.side

By default

  *.side follows Form.left (or top)

And few shorthands, e.g. “A expands hotizontally” means A.right follows Parent.right, etc.

It is actually a dumbed down version of a constraints model and is a subset of it, though it looks and feels more like boxing or alignment models. It was used in pre-constraints apple toolkits and few other products. The main difference is that these follow/proportional constraints are tree-like (cycles forbidden), when true constraint-based layout is a linear problem that requires a special solver optimized for ui-related [in]equality patterns to update in realtime.

Not sure if there is a single resource, but check these links. As you can see, some frameworks mixed layouts and extended size allocation ideas to better fit a given job. (Web has never done this, we're literally stuck with a tree of MSWords)

Constraints-based:

  https://blog.gtk.org/2019/07/02/constraint-layouts/
  https://ebassi.github.io/emeus/
  https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/AutolayoutPG/AnatomyofaConstraint.html
  https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/AutolayoutPG/VisualFormatLanguage.html

Boxing:

  https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_blocks/The_box_model#examples_of_different_display_types

Alignment/anchor-based:

  $subj
  https://wiki.lazarus.freepascal.org/Autosize_/_Layout

It seems that it positions itself as RAD-like, so not surprising. Boxing and constraints models have one huge downside – your visual interface builder always sucks.

Yes text layout is fundamentally different in the sense that text layout is about placing lines of text inside a rectangle, where RectCut is about placing the rectangles and doesn’t help much with text. It would be possible to use RectCut for text flow, but you probably wouldn’t want to, it’s more designed for a small number of on-screen panels in an application.

Core LaTeX is concerned with the flow of text in printed articles, and Knuth published the text layout algorithm “Breaking Paragraphs into Lines” http://www.eprg.org/G53DOC/pdfs/knuth-plass-breaking.pdf

Originally, HTML did the same thing, it was used to emulate the written page and layout text into a box. But not everyone wanted their site to look like a printed article, so CSS and new layout modes sprouted over the years. Today there are seven of them: https://developer.mozilla.org/en-US/docs/Web/CSS/Layout_mode

RectCut is fundamentally most similar in spirit to CSS flexbox, and fundamentally similar to a bunch of other box layout managers in other languages and UI toolkits, as you can see from the comments.

I would call that “flow layout”.

HTML includes a version of it, TeX and DTP apps use various versions of it.

Edit to add: I don’t know the details of TeX except that it uses a hierarchical “box model”. I suspect it’s fairly similar to HTML before flex-box. HTML flex feels like a refined version of Java AWT layout managers (a more successful evolution than Android’s painful variant).

The article and parent talk mostly about layout in terms of rectangles and subdividing those into smaller rectangles. The basics like Box and Flex layout are pretty simple.

Once you start adding constraints like min/max size and relative sizes it becomes more complex but still manageable. You’re still only reasoning about rectangles and their constraints.

Adding rendered text in the mix increases complexity immensely. Determining the size of rendered text is a very complex problem space in itself involving fonts, dpi, text flow, code points, LTR/RTL, ligatures and more. It’s not just rectangles anymore.

That’s half of the point of giving a desktop mode switch, that it makes the browser ignore the “no really, I support mobile” <meta name="viewport" content="width=device-width"> tag.

It’s a hopelessly bad illustration of that.

The web does a singularly excellent job of supporting varying viewport sizes out of the box, but this page actively sabotaged that by claiming to support mobile:

  <meta name="viewport" content="width=device-width, initial-scale=1.0" />

While applying CSS rules that ruin it:

  .article-card, article h1, article ul, article p, article ol {
    width: 600px;
  }

  pre {
    overflow-x: hidden;
  }

These rules are obviously bad. width should be max-width, and, well, what would you expect to happen if you tell it to hide the overflow?

(It would have been OK even with these rules if the page hadn’t claimed to support mobile sizes, as the mobile browser would have rendered the page on a larger viewport and scaled it down, more or less.)

OTOH, CSS can handle a vastly wider array of styles and use cases. I agree it’s crufty, but there are many historical / legacy reasons for it that are still in use today.

If used in practice for anything substantial, RectCut will start to acquire cruft too. First thing to get added would be resizeable / dynamic layouts. Next would be something akin to the CSS grid layout, which is already the successor to flexbox (closest CSS layout mode to RectCut).

As they say, everything old is new again.

Is... that good?