EZGui and layouts

Eric_Sluyter · May 11, 2025, 6:57am

I see there is an open PR from a long time ago from @jamshark70 about this

Update EZGui classes to work seamlessly with layouts

opened 08:20AM - 06 Oct 15 UTC

enhancement comp: Qt GUI fix proposed

Currently, attempting to add any EZGui view into a Qt layout will produce a warn…ing _Qt: WARNING: Do not know how to use an instance of class 'EZKnob'_ and incorrect behavior. https://github.com/supercollider/supercollider/tree/topic/EZGuiForLayouts is a substantial reworking of the main EZGui classes for full compatibility with layouts. The work is not completely done, however: - In EZSlider, for instance, with the normal horizontal layout, the slider occupies the entire vertical space allotted by the parent view, but the number box's height adapts to the font. It would look cleaner if all subviews had the same height, but this is not possible with the current size-hinting interface. - I couldn't find any clear spec for the layout symbols, e.g. `\horz`, `\vert`, `\line2`. I tested `\horz` and `\vert` briefly and the four classes behave reasonably in those two cases. I am not an extensive/detailed user of EZGuis, so it would help if somebody who knows these layout options better could handle them or provide advice. - This will break user subclasses, by removing `prSubViewBounds` (not needed because the subviews' bounds are now under control of the layout) and `prSetViewParams` (because subviews' resize behavior is also under control of the layout). So I would say, don't put this in 3.7. Other developers are welcomed/encouraged/begged to improve on this :) Test cases: ``` // EZSlider \horz w = Window("test", Rect(800, 200, 400, 300)).front; w.layout = VLayout( *(e = { EZSlider(w, nil, "test", nil, nil, 0.5) } ! 5) ); // EZSlider \vert w = Window("test", Rect(800, 200, 400, 300)).front; w.layout = HLayout( *(e = { EZSlider(w, nil, "test", nil, nil, 0.5, layout: \vert) } ! 5) ); // EZKnob \horz -- hmm, this is perhaps dubious w = Window("test", Rect(800, 200, 400, 300)).front; w.layout = VLayout( *(e = { EZKnob(w, nil, "test", nil, nil, 0.5) } ! 5) ); // EZKnob \vert w = Window("test", Rect(800, 200, 400, 300)).front; w.layout = HLayout( *(e = { EZKnob(w, nil, "test", nil, nil, 0.5) } ! 5) ); w = Window("test", Rect(800, 200, 400, 300)).front; w.layout = VLayout( *(e = { EZNumber(w, nil, "test", nil, nil, 0.5) } ! 5) ); // EZRanger \horz w = Window("test", Rect(800, 200, 400, 300)).front; w.layout = VLayout( *(e = { EZRanger(w, nil, "test", nil, nil, [0.3, 0.7]) } ! 5) ); // EZRanger \vert w = Window("test", Rect(800, 200, 400, 300)).front; w.layout = HLayout( *(e = { EZRanger(w, nil, "test", nil, nil, [0.3, 0.7], layout: \vert) } ! 5) ); ```

is there a reason this isn’t getting more attention? I feel like any usable solution even if not totally airtight is better than the current situation… tbh, as a relatively casual user either of the two screenshots of “funny behavior” look totally acceptable to me, if my goal is to quickly get a GUI working for this cool thing I made… if I really care about smooth appearance I will have to dig into the bowels of SCGUI anyway – and this can be fun! but I think EZ whatever can’t be called EZ unless it just works.

I had written a whole thing about this, before I thought about checking the open PRs

Currently, EZ gui elements do not work with layouts, because e.g. EZKnob() without any arguments opens in a new window.

Fixing this is not totally trivial (I tried just removing the part of EZGui:prMakeView that makes the window but no luck, I suspect the widgets currently need to know their bounds before they are made)

So, before I attempt, I’m curious: would anyone miss e.g. EZKnob() opening a new window?

I’m motivated to try because I think it’s very common, for example, to want to make a bunch of knobs, each of which has a different range and also a number box to edit the precise value and ideally a label, arranged in a grid. Each of these things individually is easy (a super-knob and a grid), but together requires a TON more work (basically reverse engineering EZKnob to make a custom knob and number box that work together with a collective action, or doing some math and resize magic if you want the grid to scale with the parent view).

The revised EZ widgets could still open in a new window if you call .front on them, like most other GUI classes

jamshark70 · May 11, 2025, 11:10am

If users don’t object to the different default heights of the different objects, and if the PR still works (which… offhand I can’t think of a reason why it wouldn’t), then it would be better than no layout compatibility at all.

I forget how far I went with it though. But it should be easier to follow the model than it was to make the model in the first place.

hjh