FIX: issue #4733 ([VID] Late switching of layout direction) #4734
Conversation
|
Still need to fix debug boxes geometry. |
|
TBH |
|
I'll leave the question of how a change in |
|
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? |
Not related.
Do you have a proposition for making it much simpler? |
2 files in red/code (perlin & mandelbrot). Those from red/red I added to this PR. |
|
Of note,
First we need to better define the model I think.
Another thing I would try is to separate concerns during refactor: position managing code, styling code, grid vs flow code, and so on.. |
|
@hiiamboris thanks for testing other scripts. 👍
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. |
|
Good writeup @hiiamboris. I'm slammed, but will try to review before too long. |
|
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.
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):
Principles:
They are also many changes and improvements to View engine itself (starting with the redesign of |
|
Thanks for sharing your plans ;) 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 If we forget about backward compatibility, some of my ideas/wishes for a layout dialect would be:
I know they are radical though and may not satisfy everyone's tastes ;) |
| system/view/VID/debug?: yes | ||
| view [ | ||
| at 1x110 base 1100x1 black | ||
| origin 10x10 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
1ec06cd to
7218fb4
Compare
I. Implements alternative reading semantics of across/below keywords:
In doing so, fixes #4733
Was:
acrossbasebelowfieldfieldNew:
acrossbasebelowfieldfieldWhich arguably is more predictable and human-friendly, esp. in stair layouts. (And if you insert
returnbetween faces in the layout below, you'll totally lose track of things :p)E.g.:
And simpler:
view [base base below base across base below base across base]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.