FIX: issue #4733 ([VID] Late switching of layout direction)

[hiiamboris]

I. Implements alternative reading semantics of across/below keywords:

In doing so, fixes #4733

Was:

Code	Meaning
across	"across this.."
base	"..BASE, place the next face.."
below	"below this.."
field	"..FIELD, place the next.."
field	"..FIELD"

New:

Code	Meaning
across	(no effect, overridden further)
base	"place this BASE.."
below	"below it.."
field	"place a FIELD.."
field	"then another FIELD"

Which arguably is more predictable and human-friendly, esp. in stair layouts. (And if you insert return between faces in the layout below, you'll totally lose track of things :p)
E.g.:

view layout [
    space 8x2 pad 5x20
    across bottom   base field base 80x70
    below right     field 60x25 base 70x70
    across          pad 5x0 base base 40x40
    below           base
    across          base
]

Old	New

And simpler: view [base base below base across base below base across base]

Old	New

---

II. Also throws an error when one attempts to change flow direction in GRID mode: view [panel 2 [below base across base base]], as results of it are (and were) unpredictable.

If someone has an idea of how we can usefully combine grid mode with flow diversion, I can implement it.

[hiiamboris]

Still need to fix debug boxes geometry.

[hiiamboris]

TBH layout is so complex that I can't count all the ways I can break it...

[hiiamboris]

I'll leave the question of how a change in layout made all ARM tests crash on zero access, and all Mac tests fail to compile, to someone else. Butterfly effect and all.. ;)
Well, maybe Travis' luck reserves ran out?
I can't reproduce any of these failures, but on both my Mac VM and Bolek's RPi, the only test that fails is "op", which is a Redbin test and it succeeds when run autonomously. Just don't start asking me what Redbin has to do with VID...

[hiiamboris]

Hmm, it looks like build failures come from master

[dockimbel]

Can we have an estimate of how many exisiting demo & test scripts we have in red/red and red/code would be impacted by such change?

[dockimbel]

I'll leave the question of how a change in layout made all ARM tests crash on zero access, and all Mac tests fail to compile, to someone else. Butterfly effect and all.. ;)

Not related.

TBH layout is so complex that I can't count all the ways I can break it...

Do you have a proposition for making it much simpler?

[hiiamboris]

Can we have an estimate of how many exisiting demo & test scripts we have in red/red and red/code would be impacted by such change?

2 files in red/code (perlin & mandelbrot). Those from red/red I added to this PR.

[hiiamboris]

Of note, space keyword already follows the logic of this PR: it applies to space between the previous and next face, not next and the ones after it.

Do you have a proposition for making it much simpler?

First we need to better define the model I think.
Let's see... Here's some comparison table with remaining questions and just undocumented findings.

Edge case	Code example	Meaning in old semantic	Meaning in new semantic
Alignment change	face1 ACROSS BOTTOM face2 ACROSS TOP face3	face1 unaffected, face2 bottom-aligned, face3 top-aligned	should face2 be top- or bottom-aligned? Right now it'll be top-aligned
Alignment in Grid mode	panel 2 [below right base base 40x40 base 50x50 base]	No way(?) to control alignment of columns except the 1st one. No way to control alignment inside each column (e.g. top/bottom/middle)	Same. Should initial alignment affect all rows/columns? Should there be a way to control alignment inside each row/column?
Direction change	face1 ACROSS BOTTOM face2 face3 BELOW RIGHT face4 face5	face1 unaffected, face2&face3 bottom-aligned, face4 appears in the same row but it's top-right-aligned, sticking out of the row but fitting into face4-face5 column, face5 is right-aligned	face1,face2,face3 are bottom-aligned, face3,face4,face5 are right-aligned (face3 is a joint point between row & column and both alignments apply to it)
Direction change in Grid mode	panel 2 [base1 below right base2 base3 base4 base5 base6]	Bugged. base3&base4 and base5&base6 share the same offset	Forbidden
Does padding affect alignment?	across bottom base pad 0x20 base pad 0x-20 base return base base base	Padding is ignored by row/column size estimator and allows padded faces to overhang from it	Same. Should we include padding into row/column size?
Padding in Grid mode	panel 2 [base base 40x40 pad 60x60 base 50x50 pad 90x90 base]	Works for the 1st row, but contrary to Flow mode affects whole column's size/offset. For subsequent rows, opposite padding axis is ignored, only the main one is used	Same. Should the opposite axis be ignored?
Space change	face1 SPACE 50x50 face2 face3	affects face1-face2 and face2-face3 spacing	Same
Space change in Grid mode	panel 2 [base base space 30x30 base base base base]	Same as padding: 1st row affected fully, following rows only count the main axis of space	Same.
Multiple returns	RETURN RETURN ..	Subsequent returns add space along the main axis	Same
Return in Grid mode	panel 2 [base return base]	Forbidden (error)	Same. Should we define it as "go to next row/column" to have partially filled rows/columns?
Origin autoupdate?	base base RETURN BELOW field field RETURN field	Docs say that last return should move position to the next column here, but they don't say (1) that the next column starts at origin/y and not where the previous column started, (2) the next column skips the previous row horizontally	Same right now. Should we have a way (except panels) to update origin for subsequent returns? E.g. each across/below/return would update origin?
Origin change	face1 ORIGIN 100x100 face2 ..	origin may be typed manually to control further rows/columns return-point, but this affects the bottom-right margin and has to be countered by origin 10x10 before closing the VID block. Also, origin change immediately finishes the row/column and starts a new one (like return)	Same. (1) Should there be a way to leave the margin as is but have more control over returns? (2) Shouldn't we rename origin to margin for clarity? (3) Should we even allow change of origin mid-way?
Origin change in Grid mode	panel 2 [base1 origin 50x50 base2 base3 base4 base5 base6]	Bugged. base3 and base4 share the same offset, as well as base5 and base6	Same. Bugged. Should origin start a fresh column/row or continue where left off? Or should be forbidden?
AT in Grid mode	panel 2 [base at 50x50 base base base base base]	Bugged (or feature?). Messes spacing.	Same. Should at take the next face out of it's column/row, or should it affect the row/column width/offset as it does now?

Another thing I would try is to separate concerns during refactor: position managing code, styling code, grid vs flow code, and so on..

[greggirwin]

@hiiamboris thanks for testing other scripts. 👍

TBH layout is so complex that I can't count all the ways I can break it...

As with Red itself, we often have to choose between putting control in user's hands versus limiting things that can go wrong. Of course, things should work for simple and common cases. How much we change VID, or break compatibility, is key. Can we make VID better but still compatible, or do we need alternate dialects. Things like resizing and constraint systems are possible extensions. In the past, I think we agreed that resizing should be supported, but a full constraint-based system (Cassowary like) might not fit well.

[greggirwin]

Good writeup @hiiamboris. I'm slammed, but will try to review before too long.

[dockimbel]

@hiiamboris

For the changes you are proposing in this PR, they look acceptable to me and I would be ready to merge it once I review the code changes in detail. I remember testing such model in the early days of VID, but dismissed it as I found the current one giving in some cases more useful results. Though, I didn't conduct a strict study about it, so I don't have a strong case right now to make for the current model.

First we need to better define the model I think.
Let's see... Here's some comparison table with remaining questions and just undocumented findings.

Thanks for starting digging into it. The points you are raising could lead to major changes in VID layout model. The current layout model is pretty much the same as in R2/VID. I was always looking up for ways to extend it, to better cop with modern design needs and different targets (like mobile devices and web pages). If a major update for VID is to be done, I would like it to be a major leap forward, well beyond the scope of this PR. Some of the possible directions of VID evolutions (just from top of my head):

• More extensive cardinal directions padding/margins and centering support.

• Adaptive layouts or sub-layouts (what the web coders wrongly call "responsive" ;-)), that allow to optionally specify rules on how the layout content would fit in a different screen size or aspect ratio.

• Auto-resizing support (maybe following the CSS grid model, as it's quite simple). The cassowary constraint solving model seems too complex both for users and implementers.

• Make VID a dynamic dialect instead of just a front-end to View face tree, like making the VID description alive and synced (dual-way) with the face tree changes. (Not sure this is doable, but worth exploring).

Principles:

• Simple for simple needs, possible to support complex needs.
• Intuitive language and semantic constructs.
• Useful defaults for everything.

They are also many changes and improvements to View engine itself (starting with the redesign of event!) that are on my todo-list since a long time. Though, we have so many sub-projects and parallel axes of development right now that I don't see how we could add more. So take this as "for the record". ;-)

[hiiamboris]

Thanks for sharing your plans ;)
I also think VID is a bit outdated, considering the variety of devices (screens & input models) modern software has to support. That's a problem with most of today's software though. It feels very stupid when I have to rotate my laptop's screen just to be able to click a button that's otherwise hidden because on developers screens it was alright to make layout this huge.

On resizing, you may be or not be familiar with my minimalistic work to support it. It deals with the very limited info - coordinates & anchors. Of course in VID we have columns, rows, alignment, flow style & direction, pinning (with at) and such, and if we saved all this info, we could make more advanced sizing strategies. I'm not sure if conversion of a layout back into VID is possible or useful, but I'm sure that if we don't lose the info available to VID, we can push it far.

If we forget about backward compatibility, some of my ideas/wishes for a layout dialect would be:

• Let go of the habit of positioning faces manually. Just throw a bunch of widgets at it, group them (to outline relations), and it should be able to construct a meaningful layout all by itself.
• Let go of pixel hunting. How much is 100px? I have no idea. Humans may think in characters. E.g. "10 characters" is a sensible size. Or they may think in fractions - 1/2 of screen, 80% of screen, etc. On some rare occasions, cm/inch may be useful. But not pixels. Pixels work against us.

I know they are radical though and may not satisfy everyone's tastes ;)

[dockimbel]

Why is at modifying the flow cursor now? That should not happen. at is meant to specify an absolute position that does not interfere with the automatic layout system.

[hiiamboris]

It's not. But debug facilities (in re-align) are rather dumb. They see at.. base.. across top base.. as a single row (the begin word points at first base). Exclusion of at items is done in another place (align-faces), which re-align doesn't know of. Previously, when across was starting a row, begin pointed at the second base and debug lines were drawn properly.

This line origin 10x10 only fixes the debug lines in this particular case, and has no effect on layout itself. To properly draw debug lines we need to remove at-positioned faces right in the layout function. I considered it not worth the effort to do so.