I’ve tagged a new release and uploaded binaries to:
https://github.com/rorywalsh/cabbage/releases/tag/v0.5.15
I’ve included a 64bit version for Windows too. Let me know if there are any problems. I know that there is an issue remaining with regards to popup plant windows. I’m still looking into that one.
Version 0.5.15 out now
This version seems to have introduced a (very minor) graphical bug. It looks like the rendering order has changed (edit: at least for plants, other widgets still seem to layer properly), so my “disabled” plant which appears first in the code previously displayed behind the flanged plant, now it appears in front of it. Because the disabled plant has a low alpha value, you can see through it partially, so the garbled text label is what tipped me off. I tested this by changing the order of my plants in the code, and it resolved it. Here’s a screenshot of this problem:
Even weirder, if I add widgets to that lower “disabled” plant, it seems that their locations are no longer relative to the plant’s location. Moving the plant’s X/Y location doesn’t move the widgets it contains, and their position shows X/Y coordinates based on the main form, not the plant. This screenshot shows the flanged instrument with the depth and feedback knobs added for testing purposes to the disabled plant using the same coordinates they had in the main flanged plant. You can see their position is being calculated wrong.
The code I had changed to test now reads:
groupbox bounds(10, 94, 360, 350), $DIS_PLANT {
rslider bounds(0, 22, 75, 75), channel("depth"), range(0, 1, .1, .5, 0.0001), text("Depth"), $EFF_KNOB
rslider bounds(135, 22, 75, 75), channel("fb"), range(-100, 100, -50, 1, 0.01), text("Feedback %"), $EFF_KNOB
}
Which is identical to their placement in the “flanged” plant, but this is how it displays:
And here is it after moving the disabled plant 40 pixels to the right, you can see the rslider widgets haven’t moved even tho they belong to the disabled plant:
Definetely something odd happening, but the problem you mention is most likely to do with the fact that your disabled plant isn’t actually a plant. DIS_PLANT doesn’t contain any plant() identifier. I did change the order of rendering to address an issue reported by Gsenna regarding plants. And although I’m not sure it’s totally at fault here, I’ve just noticed it does affect a few of Iain’s instruments. Time to rethink things.
AH! I forgot that I didn’t define the disabled groupbox as a plant because it didn’t have any controls… I had just decided to test how it behaved when I noticed the layering stuff acting weird. That clears up the second issue in my previous post.
The first issue is very minor, and easily worked around… I guess it’s really just a matter of knowing what the intended layering behavior will be. I don’t mind moving my disabled boxes to the end of my cabbage code if that’s the way it will work… it just seems odd since widgets stack with the first being lowest and the last being highest, but groupboxes do the opposite.
Either way, just let me know if I need to re-arrange them. Thanks!
The real issue is that up until now Cabbage was pretty laid back about order of widgets. It would always place a groupbox behind any widgets that were declared after it. Now it’s a little more picky, and if you do something like:
rslider bounds(20, 32, 50, 50), channel("rslider"), range(0, 1, 0)
groupbox bounds(10, 0, 200, 150), text("groupbox")
You clearly won’t be able to view that slider as the groupbox will be on top of it. I guess it makes sense that the z order to widgets is determined by when they are added to the code?
Btw, I just posted a new version there that fixes some of the issues I spotted with regards to images. From now on rendering of widgets is done based on where they appear in the Cabbage code. I think this is the most obvious and expected behaviour. I’ve also added ‘send to back/front’ functionality to the GUI editor. I’ll update the Windows builds later today.
Awesome, thanks Rory!