Cabbage Logo
Back to Cabbage Site

Is it possible to detect window size?

#1

And not just detect, but in turn be able to use the detected “form size” in the bounds of a newly defined widget?

I have a widget that I’ll call a “shader”, that is essentially a partially transparent image widget, and right now I manually set it’s bounds to match the instrument’s “form” bounds definition each place I need to use it… in other words, it should always be the same size as is available to the instrument/plugin. I use this to darken the background when something pops up for user interaction… it both darkens the background, and disables any visible controls other than what is on a layer above it.

I’m looking for a way to make this widget automatically scale itself to match the bounds of the entire instrument, so that a definition in an include file would be usable regardless of the bounds of the instrument including it.

Does anyone have suggestions for this?

#2

There are reserved channels called SCREEN_WIDTH and SCREEN_HEIGHT which return the panel dimensions in pixels. It sounds like this might be what you are after.
http://cabbageaudio.com/docs/macros_and_reserved_channels/

1 Like
#3

Thanks Iain, that’s perfect! I’d swear I had looked for them there a few weeks ago, but don’t remember seeing them.

This still leaves me in a bind tho, because of the specific way I’m trying to use them… but I’m trying to use these inside of another macro definition, like so:

#define NEWSHADER bounds(0, 0, $SCREEN_WIDTH, $SCREEN_HEIGHT), colour(20, 20, 20,235), fontcolour(255, 255, 255, 255), visible(0)

That way any instrument that’s imported the file can just add one like so:
image $NEWSHADER, identchannel("reset-tint")

Currently that doesn’t appear to work… I know I’ve given Rory quite the headache already with regards to macros, so any alternate suggestions that would make it equally portable are welcome… I’m trying to avoid having to define bounds and colors for it every time it’s used.

#4

This should work. I’m pretty sure the last round of work to macros made it possible once again to embed them within parentheses, but I’ll take a look. Could be something else causing the issue.

#5

Hey Rory, that’s fantastic to hear!

Given I had unexpected results with the “slippery combobox” too, it’s possible I only think that I’m using the newest build. I’ll download and reinstall fresh just to be sure it’s not a simple mistake on my end.

#6

I have reinstalled fresh, but both this and the slippery combobox still seem to be causing me problems.

#7

Just a polite bump on this stale topic…

I still can’t seem to use the screen size macros as expected:
#define NEWSHADER bounds(0, 0, $SCREEN_WIDTH, $SCREEN_HEIGHT), colour(20, 20, 20,235), fontcolour(255, 255, 255, 255), visible(0)

I’ve also tried setting the bounds via a UDO sending over the identchannel, same result.

If I replace the width and height macros with hard coded numbers in both test cases, everything works as expected.

#8

Looking into this now.

#9

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.

#10

Can you try this one. That’s where Travis dumps the latest build for OSX.

#11

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.

#12

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.

#13

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? :thinking:

#14

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.

#16

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.

#17

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!

#18

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.

#19

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 :wink:

#20

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!)?

#21

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 :innocent: