Cabbage Logo
Back to Cabbage Site

Little GUI widget slugs and wishes

#1

Hi,
Instead of continuing on this topic:
https://forum.cabbageaudio.com/t/widgets-should-not-share-channels-names
I thought it could be useful to have a more general one on little issues with widgets. I think there could be more to add here in the future, but here is a little one for now.

I find the rotate parameter, e.g. of labels and images, difficult to work with. It is almost impossible to position the widget by mouse and ones you finally make it, it changes again after save:

See what happens if I select a group of widgets and move them:

Further, it would perhaps be good if the anchor point would be at the “centre” of the widget bound-box and I’d prefer to specify rotation in degrees or fraction of PI instead of radians.

New rslider identifiers
#2

The key here is NOT to move the widget after you have performed the transformation. But rather get it in place first, and then transform it. Alternatively, transform it during an init pass in your Csound code.

#3

I see. The init pass rotation could be useful, but it would still be good (almost necessary) - at least for me - to be able to see the rotation during the design process. Sometimes I need to move a group of widgets when trying to find a good position on the screen. I know having this ability in Cabbage is a luxury feature, so I might be a bit spoiled here :slight_smile:

1 Like
#4

Rotating in the init pass seems to have the same issue (for me) related to the anchor point. A bit inconvenient to need adjusting the anchor point depending on the size. So to have this automatic, I’d need to read the size first and then rotate, or could there be a more elegant way of handling this?

#5

I tried cabbageSet "image_name", "rotate(3.14,10,20)". It seems that the last two arguments are not applied?

#6

This is fixed now in Git and will be available in the next Azure build which is currently underway :wink:

#7

Nice! Thanks!
Another one - rslider seems to have some kind of a lower size limit (30x30). At least for a square size I’m loosing face colour on it if I make it to small. Yeah, I know my small obsession :blush:

Another questions / wish. I often reuse the rslider range, so that I have one scale or behaviour to the left of 12 o’clock and another to the right. In many cases it is convenient to have a zero at 12 o’clock and it would be nice to have a tracker colour (the stripe around) follow from 0 to negative or positive values for example. Would it be possible to implement an additional parameter specifying where from is the tracker shown (default being minimum range value)? I hope it is possible to decipher what I mean?

#8

Hi @Samo. Yes, the style changes when you make it too small :rofl: It’s always been this way. I’m afraid that if I change this now that it will inevitably change a lot of peoples UI’s. Especially those with extremely good eye sight!

Fear not, there is a solution that won’t break other peoples plugins. We can tag each small slider, and then generate an image for each one.

Screen Shot 2021-07-06 at 09.43.27
Screen Shot 2021-07-06 at 09.43.271766Ă—946 159 KB

SmallSliders.csd (1.5 KB)

p.s. there is a slight visual quirk with the small sliders. There seems to be a small white square in the upper left hand corner. I don’t think fixing this will screw with other people’s GUIs. I’ll take a look now…

#9

Interesting! But the small type seems to mess up the colour and the marker or the inside/outside radius or something else? The upper left pixel colour depends on the colour parameter and seems to be there also for normal rsliders when are smaller than 30x30.

Does this make sense? Any possibility to have the tracker start at a specified value?

#10

The new line syntax \\ doesn’t seem to work for whatever the first parameter in new line is, e.g.

rslider bounds(232, 10, 100, 100), channel("rslider1"), range(0, 1, 0, 1, 0.01) \\
colour(255, 0, 0, 255) trackerColour(0, 255, 0, 255) markerColour(0, 0, 255, 255) popupText("0")

If I change the order it will not apply to another parameter which is the first in the new line.

#11

Possible, but a little bit of a pain. Just so we’re clear you want to restrict the amount that someone has to move the mouse in order to move from min to max?

I’ll take a look. Newline support was added before the GUI editor. I’m pretty sure splitting a widget declaration across various lines will causes issues if you then click on the widget in the GUI editor?

#12

You’re right. Now that I tried, I realized that I came across this in the past, so maybe I should just avoid splitting lines.

No I meant something quite different. Would need to animate it here, but let me try with words and pictures. Here I have zero at 12 o’clock (range from -1 to 1):
image

I’d like the following to show the green stripe from 12 o’clock to 9 instead of from 7 to 9.
image
So the stripe would go from START to current position, where START is a widget parameter. In this case I’d like START = 0.

#13

vslider seems to have the behaviour I was looking for in rslider

vslider bounds(8, 10, 108, 248) range(-1, 2, 0, 1, 0.001) channel("slider")

But see what happens here when I slightly move it from 0.
image
image

#14

I know what you mean. This might be tricky. I can take a look. So a new identifier called trackerStart() I think the simplest thing here would be to pass a value between 0 and 1. The default behaviour would be trackerStart(0), which will cause the tracker line to be drawn from min value.

Even though this is default behaviour for vslider's, I’m hesitant to override the existing behaviour for rslider's as it will once again change a lot of existing GUIs.

#15

Of course breaking old stuff is no good. But I appreciate if you can consider adding something like the trackerStart if possible.

1 Like
#16

Following on this, I can add an image in the background manually but I’m wondering if there is a way to put it in the background with cabbageCreate?

And another question on this: what does mouseInteraction parameter do? I don’t find it in the docs. Is it to prevent sending 1 and 0 to the channel on mouse clicks?

Please let me know when you have the time to check also:

And just a reminder, not sure you noticed:

Maybe there is a bug with tracker in vslider?

#17

I thought I could get rid of the dot in the upper left corner for small sliders by having an image with an outline. But there seems to be something wrong with this or am I doing something wrong?
The result of this:

image bounds(200, 40, 40, 40) shape("circle")  channel("image1")  colour(255, 255, 0, 200) 
image bounds(250, 40, 40, 40) shape("circle")  channel("image2")  colour(255, 255, 0, 200) outlineThickness(5) outlineColour(255,0,0)
image bounds(300, 40, 40, 40) shape("circle")  channel("image3")  colour(255, 255, 0, 200) outlineThickness(10) outlineColour(255,0,0)

is
image

#18

Sorry for piling up at the moment!

If I have markerStart on rslider and I move the widget with a mouse, markerStart disappears.

I guess this goes along my preference of moving the widgets by mouse rather than using cabbageCreate. At least for less grid-like interfaces (with varying widget sizes and types), mouse positioning seems quite a necessity.

#19

That’s gone in the latest beta build. I nuked it as soon as I saw it.

I’m already ahead of you here. I am in the process of adding a way of moving the z-order to widgets. I think this is going to be necessary if one mixes the creation of widgets between the Cabbage section and the Csound orchestra.

It disables mouse interaction so that a widget under this widget can receive mouse presses. Sorry, I’ve updated the docs, I didn’t realise it was missing :wink:

Could be. The v and h sliders don’t get used much these days. I’ll take a look when I get a chance.

#20

Thanks for all these fixes!

See outlineThickness … Another low-priority slug? Or intentional?