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.
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.
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
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?
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
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?
Hi @Samo. Yes, the style changes when you make it too small 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.
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..
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?
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?
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):
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.
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:
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:
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.
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
Could be. The v and h sliders don’t get used much these days. I’ll take a look when I get a chance.
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!
