Grid and grid-snapping position?

[mxmilkiib]

How about an optional grid, plus the option to snap nodes to that grid?

[Houston4444]

I suppose it concerns HoustonPatchbay more than RaySession (that is not strong).

I don't understand the point at all, could you be more verbose ? We should snap the top left corner of boxes to a grid, why do it ?

[mxmilkiib]

It really helps my head to have the graph nodes all lined up in some consistent manner.

Snapping to a grid would make this process a lot quicker to get done.

Snapping the top left corner sounds like a viable method.

[mxmilkiib]

Even just a repeating background image that's a tiling grid pattern to line things up along/against to would be great.

[Houston4444]

It is quite hard to imagine, it has big conflicts with the "prevent overlap" option. It means that boxes should be moved by it to a grid, with a box spacing distance dependent of the grid, etc...

Even just a repeating background image that's a tiling grid pattern to line things up along/against to would be great.

You can easily do that now, editing a theme, you just have to define a checkerboard image as background.

[mxmilkiib]

Thanks! I'll look at how to theme at some point soon.

I mean, this is two requests in one really. The relationship of units to a grid must be harder than just showing a grid.

Do you use the same graph positioning JACK metadata as Carla?

[Houston4444]

Thanks! I'll look at how to theme at some point soon.

Here is the theme help: http://raysession.tuxfamily.org/manuals/patchbay/en/theme_edit.html

Note that you can set a background image and a background color. The background color is front of the background image, it is useful if your color has transparency.

Do you use the same graph positioning JACK metadata as Carla?

No, because I don't see any interest for this, other apps would do nothing with the box positions. Even if theses apps contain a patchbay, box would not have the same sizes.

[mxmilkiib]

First attempt with a 300x300 background image with a basic GIMP path with a stroke fill.

[Houston4444]

Nice, it looks like tiles.

Don't hesitate to make a PR with a new theme, even if nothing changes except the background. Maybe we could change the theme directly, I don't know, "Light Blue Rose" is the only theme I made that I never use, I've done it for accessibility, but it is too lightly for my eyes.

[mxmilkiib]

I'll get back to a theme PR at some point soon. (Though an option to dynamically change the background and background-image properties for all available themes might save on doubling the number of themes).

Grid snapping; I am using GNU Radio for the first time, and there is no grid but there is snapping, e.g., every unit bumps around when dragged, moving in only 10px increments either vertically or horizontally. There is no grid, no visible one anyway, just the assumed one provided by this unit movement constraint.

[Houston4444]

an option to dynamically change the background and background-image properties for all available themes might save on doubling the number of themes

I'll take a look, maybe something is possible.

Grid snapping; I am using GNU Radio for the first time, and there is no grid but there is snapping, e.g., every unit bumps around when dragged, moving in only 10px increments either vertically or horizontally. There is no grid, no visible one anyway, just the assumed one provided by this unit movement constraint.

Yes, I thought about that. The most important problem comes from one of the most important features: prevent overlap.
It is designed to space the boxes a distance of N points (N depending on theme, 4pts by default). If you wrap a box with another box just below, this other box goes up to join the first one. So, the question is, what to do with that ? Should I set this spacing to 10 ?
if the grid unit is 10pts (I don't speak about pixels, because it depends on zoom), should I increase the box width and height to the next multiple of 10 ?

I don't say it is impossible, and I see the design interest, but it is quite long to do.

[Houston4444]

I just made some tests modifying HoustonPatchbay to position boxes in a grid. The idea is finally quite simple, cells have margins, box sizes are increased to fill all the cells (except margins of course).

In the Y axe, cells height can't be very high, only because having a big empty space below the last port is quite ugly.
In the X axe, cells width can be quite large, then the box widths can't be just a little different, which looks much nicer.

It needs some code adjustments of course, but not so much, and it seems to be very nice.
Cells width and height could be adjustable by user.

So, soon or later, I'll do that. Good idea, thanks !

[Houston4444]

Ok, it has been done with many other features. see #23.