Vertical slides

That’d go a long way in terms of legibility :raised_hands:

˙uᴉʍ ǝɥʇ ɹoɟ ʎʇᴉlᴉqᴉƃǝl

5 Likes

I don’t understand what the problem would be with horizontal text + vertical layout?
Doesn’t that actually help with fitting more of the definition on screen with less scrolling?

Imagine a slider. It is made up of two long elements; the name and the rail. The name will be horizontal as it is text, and if the rail is to be vertical the slider as a whole will be both wide and tall. If both the name and the rail are horizontal, a slider will use fewer pixels.

The same is true of input and output parameters. Right now the height of a component is determined by some constant factor multiplied by the max(input, output) count. No matter how long the names of the parameters are, and no matter how many modifier icons there are next to them. If the input were to be along the top of the component, then the width of the component is the sum-total of the width of all the inputs, which can be significant if custom names have been set. Inputs and outputs will switch to a two-character format in GH2 (twice the width of GH1), plus you need a fair amount of white space between labels if they are aligned horizontally, much more so than when labels are aligned vertically.

Loose parameters tend to be wider than they are tall, which means the average distance between the grips of adjacent parameters will be further apart if the grips are on the top and bottom. This in turn means the wire-density of the overall graph will be lower as well.

Another problem is groups. Group names are typically quite long and it thus makes sense to align them either along the top or bottom edge of the group box. But in a vertical layout that’s where all the wires enter and exit the group. These UI elements will overlap far more often in such a scheme.

In case of horizontal slider I would put the name and slider on top of each other. Compacter and keeps the name close to the value - less tiring eye travel.

1 Like

Is that still true if you have a stack of sliders on top of each other?

Also note that the name is often shorter than the rail, so even though you’d double the height of the slider object, the width will reduce by less than half.

Yes. The name I generally use are long. And for grouped sliders I find I get ‘blind’ by all the sliders being right on top of each other. The names on top would be a great visual help.

1 Like

Thanks for the explanation.
I see what you mean now about components with many input or output parameters re. horizontal spacing.

Incidentally, some old node-based programming environments for audio, like PWGL and PureData did include vertical graph layout and sliders (not that they are shining examples of readability though, so I’m not sure this is an argument in their favour).

It may be a good layout option to have. Something to experiment with certainly.

1 Like

Slightly off topic, but certainly on this topic:

Did you give any thought to the suggestions on enabling an orthographical/rounded wire option (as per this thread)?

Edit: Maybe orthographical isn’t actually the right description here.
Edit II: No wait, it is, assuming the meaning of “having perpendicular lines”.

Aye, while driving from the grocery (Finndependence snacks etc) back home I was thinking this some over.

When the name is layed out on top of the slider I’d probably also like to have a small indent for the slider, preferrably something that is not dependening on name or slider size. This layout could be either left or right adjusted.

I just realize that this is still about horizontal sliders. For vertical sliders there’d probably other, better layout ways.

Nothing specific. I do not like the way current wires turn into giant S-shapes when the start and end points are roughly aligned vertically. However I do like the fanning nature of the smooth bezier wires. If various wires come into the same input, and they all arrive horizontally, it will be difficult to count them and see what sort of dash-pattern they have.

At any rate, some experimentation will be required and I think it makes a lot of sense to make the wire shapes more flexible, even if, in the end, there isn’t a user option for it.

2 Likes

How about creating a special object called a Node which, when connected to another Node, makes the connection using a straight line. Otherwise it connects using the standard Bezier curve.

That would require determining what component the Node is connecting to and from, but you’d really only have to determine if it was another Node or not.

Or maybe when someone requests a Node you put 2 on the canvas, connect them together with a straight line wire, and just use standard wires for input and output.

I really like the simplicity of being able to figure out the shape of a wire from only its end-points. No further context required.

Hello,

since you asked me how to do it, and although David doesn’t like the graphics (…yet) you can still use it to do top down definitions :wink: :

here is the hack,

  • make sure to unblock the gha, by right clicking on the gha

  • the first component on a open grasshopper instance (not file) needs to be the wire injector component. After the solution was running once you can delete it. If not the hack doesn’t work

WireInjection.gha (19 KB)

wireTest.gh (3.9 KB)

wi

2 Likes

Many thanks - will let you know how it works for me.

Wow - amazing. It’s great. Thanks a lot.

Can you explain why some wires have different colors? And if there is a way to control that?

I like the idea of colouring the wires to distinguish when many components are in a definition. I’m not sure how to do this yet, just a test. Right now colours are determined by the x-distance from the two components. if left to right it gets more blue if from right to left it gets red. If x difference is very great its red only. But as I said in previous posts: I’m just playing around with it. Its nothing of being satisfied with it yet. Just the prove of concept

Got it - I played with a couple of my more complex GH layouts and they really do benefit from your enhancement. I guess I’m not sure why David doesn’t think your approach is a good idea. It seems obvious to me that it is.

After fussing with your enhancement it did seem that the X distance was what was determining the color of the wire. So I was expecting that to be the case. It is nice that you are able to control the wire color.

I did notice that some of the wires seem to be formed by 2 lines rather than one. Is that just a quirk of my graphics card (nVidia GT750), or is that something you are doing?

It didn’t take me long to come up with a different idea for your enhancement. Of course I have no idea how feasible this might be, but something that would greatly improve it’s utility would be to make the corners of the wires user controllable as far as location goes. Could you put a small dot at each of the corner locations and make them clickable/dragable?

I wouldn’t say he doesn’t like the idea, its just the colours I guess :wink:

yes, x distance. The colour aspect is quite useful, however I’m limited when its about random colour because I can only change code inside the drawing method, without valid access to other functions, fields and objects outside of GH_Painter. That’s the drawback of this method, which answers your last question:

Nowadays I tend to say everything is possible as long as you sacrifice enough time and effort.
However this particular approach isn’t suited to do that, although its a very good idea.

No I don’t think so, its probably a result of how it is drawn

Yup - been there, done that.

Thanks for a nice GH option that will be very handy in some circumstances.