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.
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.
Thanks for all these fixes!
See outlineThickness … Another low-priority slug? Or intentional?
Fixed. New build triggered But be careful you don’t use odd numbers for outlines. It will not line up right.
Super! Thanks!
This fix apparently scrambled something else.
See the result of
image bounds(10, 102, 373, 58) corners(5) colour(30, 30, 30, 255) outlineColour(255, 255, 255, 100) outlineThickness(2) channel("image100")
image bounds(10, 166, 373, 58) corners(5) colour(30, 30, 30, 255) outlineColour(255, 0, 0, 100) outlineThickness(2) channel("image101")
image bounds(10, 166, 373, 58) corners(5) colour(255, 100, 0, 30) outlineColour(255, 0, 0, 100) outlineThickness(2) channel("image102")
in build #20210708.3 Merge branch ‘develop’ of https://github.com/rorywalsh/cabbage into develop (left) and #20210708.4 fixing outlineThickess issue for image widget (right)
There is some transparency change and
note also the line thickness change.
No stress if you don’t manage over the weekend I’ll make use of an older build for now, because I hardly see my widgets now (transparency issue).
Yup, I definitely screwed something up. Sorry, I’ll try to get that sorted asap…
I pushed for a fix for this now. Latest Azure build should have it. Apologies for screwing this one up 
It looks normal now:
I’m not entirely happy with the drawing. I might try using a path for these widgets in the future. And I also noticed a long standing ‘bug’ if you could call it that. But the outline of the rectangle is drawn over the underlying rectangle. So the outline colour may be affected by the underlying rectangle colour depending on the alpha blend. I can’t imagine that’s useful for anyone 
You’re incredible! Thank you for so fast fixing! It is so exciting to see Cabbage getting better and better day by day, hour by hour! 
Well, I guess some little steps backwards sometimes are inevitable on a real journey
I’m sorry to return to this with a fresh new issue. The last fixes gave birth to a “fantastic” new little Cabbage destroyer! It has to do with checkbox and trighold that I use to blink a “light indicator”.
The code below used to work before. Now it is (1) blinking kind of randomly and it seems to mess with the form, because (2) it doesn’t stop blinking after I turn the instrument off, and (3) it also causes rslider to jump around (you get that when you move the slider to some sweet spots).
Please try running this simple example:
<Cabbage>
form caption("Test") size(350, 200), colour(0,0,0), guiMode("queue"), pluginId("sfi1")
rslider bounds(10, 10, 140, 110) range(0, 100, 0, 0.5, 0.0001) channel("slider1") colour(200, 200, 200, 255) trackerColour(200, 255, 200, 255) markerColour(0, 0, 0, 255) popupText("0")
checkbox bounds(150, 24, 20, 20), colour:0(255, 255, 0, 150), colour:1(255, 255, 0, 255) channel("blinkCheckBox"), value(0), shape("ellipse"), active(0) automatable(0)
</Cabbage>
<CsoundSynthesizer>
<CsOptions>
-n -d -+rtmidi=NULL -M0 -m0d ;--midi-key-cps=4 --midi-velocity-amp=5
</CsOptions>
<CsInstruments>
ksmps = 32
instr 1
kMetro = metro:k(cabbageGetValue:k("slider1"))
cabbageSetValue "blinkCheckBox", trighold:k(kMetro,1/ksmps) ; blink
endin
</CsInstruments>
<CsScore>
;causes Csound to run for about 7000 years...
f0 z
i1 0 z
</CsScore>
</CsoundSynthesizer>
[edit] I actually had to go back to 2.7.5 to get rid of it, haven’t tried 2.7.6.
For now I can solve this by using cabbageSet on an image within a special devoted triggered instrument, but it seems a less elegant solution to blinking lights. I’d also be interested in any comments/suggestions on this.
This should be fixed now. I just triggered a new build. It was a recursive loop in the checkbox widget, but honestly, I can’t see how this worked in earlier versions. The last change made to the checkbox class was in April. Can you test the latest build?
I’m glad you found the bugger and will test soon when it builds. I’m quite regularly updating beta versions last few months and I tested today with 2.7.5. Strange indeed. Hopefully there was not another recursive loop spinning in the opposite direction so they cancelled each other 
Now it works. Thank you!!!
Hi Rory, congrats and best wishes for the baby and the family!
A quick question: if I have a custom identifier and I click the widget or I move it, the identifier is erased.
Would it be possible to remedy this little nuisance?
Agreed, totally annoying behaviour. I think the new build system is almost ready, so I can start pushing out some bug fixes / feature in the next week. 
Two questions:
combobox items at init, e.g. cabbageSet “combo”, “text(“A”,“B”)”Thanks!
I fixed this a week ago, but I’m still trying to put the finishing touches on the new build system. I should hopefully have new beta builds ready for later this evening
I think this is only possible if you set the channel type to string, as a combobox that can be automated by the host cannot have its items changed at run time.
Thanks!
The changing of items makes sense (now again). I read it before in the docs, but managed to forget and think that the names list would be an attribute just like colour. So, I guess cabbageCreate might do the job … as long as I am not mousing on the widget after.
yeah, it’s because the host assigned a range to any widget that is automatable. If one changes this afterwards it will mess up the host automation. That being said, it should be possible with string channel comboboxes as these are not automatable.
I actually used automatable(0) but this still doesn’t permit changing the items, right?
I see that this works, but I still prefer the default behaviour, it seems easier to associate with array values and shows 0th item as default/initial, while with string, no item seems to be selected initially (but maybe that’s easy to change with some initial value?)…