Just pushed a fix to github, should have a new build for OSX in a bit. I’m just waiting for Travis to do its thing.
Is it possible to detect window size?
No luck so far. I confirmed the lite binary in the app folder got updated with the latest from today, and first I tried using the style macro:
#define NEWSHADER bounds(0, 0, $SCREEN_WIDTH, $SCREEN_HEIGHT ), colour(20, 20, 20,235), fontcolour(255, 255, 255, 255), visible(0)
No luck, so next I tried setting bounds when I toggle the widget’s visibility, like so:
chnset sprintfk("visible(%d) bounds(0,0,$SCREEN_WIDTH, $SCREEN_HEIGHT",kresets), strcat(Schan_prefix,"reset-tint")
Lastly, I tried giving the bounds as args to the sprintf, like so… this one doesn’t even compile:
chnset sprintfk("visible(%d) bounds(0,0,%d,%d",kresets,$SCREEN_WIDTH, $SCREEN_HEIGHT), strcat(Schan_prefix,"reset-tint")
I’ll run a few stripped down tests with the screen size macros tonight and see if I can get any further with them.
I just realized I should test the second method I tried WITHOUT using the same in the macro from the first, that could have broken it… will test right after this.
As an aside, something else odd I noticed today; when the “shader” wasn’t appearing behind my popped up groupbox… I was able to click and alter widgets that were completely hidden by the groupbox. I don’t know if it’s always been that way, but it kind of seems unintuitive to me.
Ah, you’re trying to use a macro within a macro. Sorry, I hadn’t considered that use case, I was just trying to get it to work as a macro itself. It might be a lot trickier to get it picked up when it is part of another macro.
Well, I’ll take any way I can get it to work, in this particular case…
The widget in question already has a UDO associated with toggling it’s visibility, so if I could set the bounds there I would, but that doesn’t seem to work either.
My goal is to be able to define a widget style like so:
#define SHADER image colour(20, 20, 20,235), visible(0)
And then call it without having to consider bounds, or at least nothing past “0,0”… like so:
$SHADER bounds(0,0,0,0), channel("example"), identchannel("example-c")
However this widget ends up inheriting the screensize is irrelevant to me… maybe that’s helpful? 
With the current version can you not do:
#define SHADER image colour(20, 20, 20,235), visible(0)
$SHADER bounds(0,0,$SCREEN_WDITH, $SCREEN_HEIGHT), channel("example"), identchannel("example-c")
But I’m not sure how useful this is unless you can apply simple mathematical operations on the macros, like $SCREEN_WDITH/2, $SCREEN_HEIGHT*.24, etc.
I think I misread that on the last reply…
No, that did not seem to work.
The reason it’s useful is I’m specifically trying to make this widget ALWAYS fill the entire screen, regardless of the overall form size.
Ok, third time is a charm. I see what you’re saying, and I think I got it working.
The bounds() needs to be used when calling the style macro, it can’t be part of it’s define.
That will work for now, tho I’m curious why I couldn’t get it working with a chnset to the ident chan with a new bounds set with sprintfk.
Either way, this looks like it might be working, so I’m happy. Will test some more.
Edit: confirmed working… thanks for the help once again!
You know you could always set the widget to be absolutely huge. The OS will not draw any parts of it that are off screen so there shouldn’t be any performance hit.
I had originally done that, but it was always ending up not quite big enough… every now and then I’d have to go and make it a little bigger, over and over again. I figured I wanted to find a more elegant way.
Which leads me to yet another idea… In addition to $SCREEN_WIDTH and $SCREEN_HEIGHT, could we maybe also have $SCREEN_BOUNDS which basically expands to the equivalent of:
bounds(0,0,$SCREEN_WIDTH,$SCREEN_HEIGHT)
Obviously it can’t use the existing macros because of the nested macro limitation, but functionally I think you know what I’m getting at 
I do know what you’re getting at. It wouldn’t be hard to implement, but I just have to be careful of how it will work with the blasted GUI editor. I dare ask, but while I’m at it, are there any other reserved macros you would like introduced(be gentle!)?
Bad news, if I’m not crazy… I’m seeing a bunch of combobox slip again =\
Man… now’s my big chance and I wasn’t ready! I honestly can’t think of any others at the moment… unless maybe hosts typically provide a way of knowing the difference between playback and a disk render? I wouldn’t mind being able to change a few behaviors based on that such as the gui update rate and maybe ksmps too.
But here’s a few other global behavior type requests…
Could imported widgets assume their default X/Y size if none is given in the bounds? For example:
TestButtons bounds(46,2), channel("main-"), namespace("test")
Would show the widgets at position 46,2 with their original sizes unscaled
trackfrom(value) for sliders. Instead of assuming the tracker should start at the lowest value of a slider’s range, starting from an arbitrary value would allow a “symmetric” tracker, for example:
rslider range(-1,1,0,1,.1), trackfrom(0) text(“Pan”)`
At 0 there’s be no line at all, and if pulled to -1 or pushed up to 1 the tracker would appear over the appropriate portion. I originally just wanted trackfrom0(bool), but I figured it might be useful to allow other values in the future too.
And I’d also still love a way to disable automation for certain widgets, such as GUI controls 
- If you use the
pos()identifier then I think the default width and height will be provided instead. - I generally use this example from Oeyvind to test slippery comboboxes. And yup, somehow I see them again now in the plugin build. Apologies for this.
- I’m not sure about the trackfrom idea, that’s why we can set default values for out sliders, so you can have them start anywhere? Or what am I missing?
I’m not sure what you mean…
TestButtons pos(46,2), channel("main-"), namespace("test")?
It’s not about the value and defaults, it’s just about visually where the tracker around the rslider would get drawn. I’ll try to explain it better; here goes:
Currently if I do an rslider with range(-1,1,0) the tracker will already be drawn from -1 to 0… or to whatever other value is selected. In other words, it’s trackfrom(-1) by default.
If it were rslider range(-1,1,0), trackfrom(0) then by default no tracker would be visible at 0, but if you rotate the slider down to -.5 the tracker appears from 0 to -.5. The tracker would always be drawn from 0 to whatever the current value, allowing you to create “symmetrical” trackers around the rslider similar to how the tracker on a vslider with both negative and positive range works.
Yes, I see you point now. I’ll need to take a look at the painting routines and see how easy that might be to implement. I see now you were talking about imported plants with the bounds issue. Did you try using just pos(), we might be lucky
I honestly have no idea what you mean by using pos()… if you hadn’t meant this:
TestButtons bounds(46,2), channel("main-"), namespace("test")
I also tried this just in case:
TestButtons pos(46,2), channel("main-"), namespace("test")
pos() is also an identifier. You can use it and size() instead of bounds()
rslider pos(10, 10), size(100, 100) ...
I just don’t know if that works with imported plants…
I don’t know why, I’ve never worked with pos/size… only bounds. Doesn’t appear to work with imported widgets tho, like I said, I had tried:
TestButtons pos(46,2), channel("main-"), namespace("test")
That’s what you’re suggesting, right? If this did work tho, it’d achieve what I’m trying to do.
Digging up a fossil here… any thought on the ability to use “pos(x,y)” with imported widgets, letting them inherit their defined sizes?
Forgot this was in the same thread, this was also something that could be very useful to me… a way to quickly define that something will always that the entire available screen real-estate.