-
Notifications
You must be signed in to change notification settings - Fork 415
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FIX: issue #4733 ([VID] Late switching of layout direction) #4734
base: master
Are you sure you want to change the base?
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 ;) |
@@ -8,6 +8,7 @@ Red [ | |||
system/view/VID/debug?: yes | |||
view [ | |||
at 1x110 base 1100x1 black | |||
origin 10x10 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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:
across
base
below
field
field
New:
across
base
below
field
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.:
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.