It would seem that trying to embed structs and scalars for graphical elements in GOP subpatches is glitching out something nasty. Draw commands work well until the GOP property is turned on, and then the canvas size gets huge and scrolling gets lost on something like an infinite scrollbar treadmill. Ive been super eager to start designing UI elements with scalars,, but the inability to nest structs and scalars in GOP subpatches is posing some real limitations/frustrations... is anyone else experiencing this? Am I doing something wrong, or is this a bug?

I take that back-- you probably can do the responsive thing using [draw g].

I can give you a demo if you want.

yes please

@th8a Here's a quick hack:

responsive-demo.pd

The hack is that I currently don't have an easy way to do clipping, so I'm using grouping and opacity to work around that.

The logic for the keyboard is: when the scaling factor is large enough AND the proportions of the box are wide enough, the piano appears. Otherwise it hides itself. You could define other size/position changes for each widget based on the size of the container.

As hacky as this is, I think it's still easier to comprehend than GOP's behavior.

Also notice that there are only two fields to the struct: x and y. That means if you copy and paste the widget, the only data saved with the scalar are the x/y coordinates. If you wanted to be able to have multiple collections of widgets operating independently you would need an additional field in the struct for each piece of data. For example, adding xSize and ySize would allow you to save the dimensions of each scalar. (You'd also have to change the guts of the drawing routine to fetch and set those values.)

Hwell son'bitch! I finally got back from my folks place today and had a chance to check this out. I took your patch and made it a gop, scaled it accordingly and it woked without crashing. This method seems like a more sensible way to go for scalable scalars. Having to anticipate the number of instances by changing the struct's variables would defeat my idea to make an easily accessible abstraction to bottle and give away to the next guy, or reuse in multiple projects though... Since $0 naming is out, can you think of any other way to take this concept and make it easily called on as an independent abstraction?

@th8a Would you be shipping a scalable square-circle-triangle-piano, or do you want to ship a library that allows users to make arbitrary combinations of squares, circles, triangles, and pianos?

I suppose it would be the latter, though what i am trying to do is make a graphical abstraction, like this button here for instance... Save it as an abstraction and then use it like an object or external. I could call it multiple times in a patch and each instance would operate independantly, remembering it's size and placement. I could put the patch up on this forum, and anyone could easily use it in their patches, etc. I suppose I would want it to operate like a graphical array, in that it is a UI element that can be used allover and easily sized and customized. If I can figure out how to get that to work, then I plan a whole library of nice looking UI objects, like knobs, faders, buttons... maybe even some MAX object clones like [live.grid] etc. All easily called on and able to customize like changing size, colors, placement etc.

That's certainly possible. I'll show a demo when I get a chance.

The only thing missing atm is the possibility to define a "drag" event in editmode for scaling the scalar. That's why I put it in runmode on the other demo.

@jancsika That'll work. I'd start with that, and then it sounds like you plan to add the drag functionality in edit mode at some point, which could make it that much better, but still cool til then