[Proposal] Horizontal Lines as Execution Helpers

[gregsn]

You know that from Riot chat: Above are old entries. Below come newer entries.

Wouldn't it be nice to have horizontal lines in your toolbox, that you can place into your patch and by that instruct the system to execute everything above before executing the nodes below?

This is another idea for quest #15.

The tricky part of this proposal:

• Can the line have a left end and a right end? I don't want those to run through my whole patch.
• If yes: Do I have to assign it to a moment/operation to make clear where it shall be active?
• If I don't have to assign it: Is it affecting portions of my patch that are far to the left/right on different moments?
• What if don't make use of them: Will still the old behavior be used? (Which might be determined in a non-visual way, but at least doesn't break my patches)

[gregsn]

We could define it like that:

• The line is working for ALL moments
• Two nodes
  • where one is above and one is below
  • where the line is spacially nearby (x coordinate) get ordered by that thing: the one above gets called first.

Spacially nearby could be defined as

• an imaginary line connecting both node centers crosses this line or
• both within X-Line-Range: for both nodes this is true:
  • (line.Left <= node.Left <= line.Right) OR (line.Left <= node.Right <= line.Right)

[velcrome]

It is a neat idea. It would make a great decorative element for one, no doubt. But let's focus on the functional problem we want to solve with it for a second:

Quite often the patcher needs to decide the order of downstream branches, especially when working with Class objects.

My work-around is commonly an if-region as some frankensteined intermediate terminator/pass-through collector

An alternative would be to redo the Frame again, and make it a little more like curly brakets { } in other languages to mark a (nestable) code-block, but ux-behave more like any other region (except that you can freely link in and out without auto-paired input/output)

I cannot sincerely give my opinion about the left-right issue you mentioned. Would need to have your proposed bar in play (at least decoratively) to explore if this is actually a ux issue (maybe during heavy refactoring? or for very messy quickpatches, but then they usually don't contain too much decoration anyway?)

Let's hope we hear some more thoughts on this

[gregsn]

Thanks for the feedback, Marko! And glad you'd even classify it as a "great decorative element". The left/right issue probably isn't a big issue. The line has it's beginning and end, and by that clearly should only influence the nodes in that "column".

---

Regarding your proposal: I find it fascinating how many ideas we can develop for what shall be a counterpart to ; in most imperative textual languages. And I have to say that I like your idea as well! Getting away without even introducing a way of expression, just by enhancing the expressiveness of a Frame sounds interesting. There are, of course, many pros and cons to each and every proposal, and these are so subtle and hard to come up with when you can't play with the proposed elements... (For that, it would be great to have a patch editor at some time that only is for sketching.) That's why I would like to encourage you to open a new Proposal issue and link refer to Quest #15 within it. That way we can in the end discuss on a high level within the [Quest] issue and discuss the details of each proposal inside their own [Proposal] threads.

To be moved to your proposal thread: I am not sure about the comparison to code blocks in textual languages: A code block {} normally is coming with a local scope, which in VL probably would be a region without any input and output (A region comes the issue that you can't link out of easily. By that comparable to the scope in textual languages.) But that's just a nerdy side note.

When looking at your proposal closely, we'd need to ask questions like:

• Can I overlay my patches with Frames the same way as before or would I need to take extra care? It didn't have any meaning up to now. Isn't it nice to have an element inside a visual language that only talks to the eye, without any attached semantics that I might not care about?
• When using a Frame for Execution ordering: Would I typically use it around the nodes that should execute first or around those that should get executed later on? (...) But we should have this discussion in the other thread. If you would do the proposal: that would be great!

Thanks for your help!

[cnisidis]

I agree with @velcrome for one and main reason, the horizontal lines will inevitably push the user to work on the vertical axis which is not always convenient. The idea of an imaginary column which will be defined by the start and the end of the line can be even more confusing or not always very noticeable. One of the great things that comes with VL itself and it should remain as is imho, is the non-linear way we are patching, and an element as the line would probably break this feeling and the workflow. Frames and Regions would be an answer indeed or even "blobs" (so you may overlap parts of each). The z-index (as is in "Foreach" loops ie) is a possible answer to the order that things should be executed with the main problem (that I am usually facing) that there is a tension to go towards the center of our imaginary plane, so the available space is getting smaller and smaller and it is frequently needed to rearrange everything.

[gregsn]

the horizontal lines will inevitably push the user to work on the vertical axis which is not always convenient.

This, of course, is a direct consequence of the proposal. However, most patches that I have seen don't need this instrument at all. We are talking about corner cases. And to have enforced pattern (nodes that must execute first come first/above) separated by a line to underline that this is important is good in my view. But yes, it is a consequence that some patches will get more vertical than with other ways of expression.

The idea of an imaginary column which will be defined by the start and the end of the line can be even more confusing or not always very noticeable.

Maybe this column could be visualized, in order to materialize it. Maybe this is just a styling topic in the end?

Let's discuss the other proposals in the meta issue #15 or in their own proposals.