Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update EZGui classes to work seamlessly with layouts #1685

Open
jamshark70 opened this issue Oct 6, 2015 · 12 comments
Open

Update EZGui classes to work seamlessly with layouts #1685

jamshark70 opened this issue Oct 6, 2015 · 12 comments

Comments

@jamshark70
Copy link
Contributor

@jamshark70 jamshark70 commented Oct 6, 2015

Currently, attempting to add any EZGui view into a Qt layout will produce a warning 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)
);
@jamshark70 jamshark70 added this to the 3.8 milestone Oct 6, 2015
@snappizz snappizz modified the milestones: 3.8, 3.9 Jan 15, 2017
@snappizz snappizz modified the milestones: 3.9, 3.9.x Oct 28, 2017
@shimpe

This comment has been minimized.

Copy link
Contributor

@shimpe shimpe commented Mar 4, 2018

it would be nice if this issue could get some attention!

thanks

@retroriff

This comment has been minimized.

Copy link

@retroriff retroriff commented Mar 1, 2019

Same problem here. EZ wrapper classes can't be attached to layouts:

ERROR: Message 'asView' not understood.

@jamshark70

This comment has been minimized.

Copy link
Contributor Author

@jamshark70 jamshark70 commented Mar 2, 2019

Bit disappointed to note that my questions went 3.5 years without any attention. OK.

Well, if I have time, I'll try to fix this up and make it a pull request.

@geoffroymontel

This comment has been minimized.

Copy link
Contributor

@geoffroymontel geoffroymontel commented Mar 19, 2020

I've just run into this problem :)

@jamshark70

This comment has been minimized.

Copy link
Contributor Author

@jamshark70 jamshark70 commented Mar 19, 2020

Make that 4.5 years now.

Requoting the questions:

  • 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.

See https://github.com/supercollider/supercollider/tree/topic/EZGuiForLayouts.

@shimpe

This comment has been minimized.

Copy link
Contributor

@shimpe shimpe commented Mar 19, 2020

If it will break user code, perhaps another option is to make a new version of EzGui classes (with a different name), and deprecate the old ones?The new ones then have no legacy behavior to worry about.

@jamshark70

This comment has been minimized.

Copy link
Contributor Author

@jamshark70 jamshark70 commented Mar 19, 2020

If it will break user code, perhaps another option is to make a new version of EzGui classes (with a different name), and deprecate the old ones?

Sure, I'd be ok with that. (I eventually added LayoutValueSlider in one of my Quarks for exactly this reason.)

The weakness in size hinting is extremely annoying though. We might just have to live with it, as almost half a decade later, there's no concrete idea how to improve it.

The problem is: Currently you can specify either a fixed size (in either dimension) or a maximum, but the interface has no way to express the idea of a view that always conforms to the parent view's size (i.e., if the view is a member of an HLayout, its height may reasonably fill the entire HLayout's height, or width in a VLayout). Slider behaves this way by default, but NumberBox does not, and I could never find any way to make it do so. So an EZSlider in an HLayout with a relatively large height will look stupid (the number box will be considerably less tall than the slider).

To make it not look stupid, size hinting needs a new feature.

@jamshark70

This comment has been minimized.

Copy link
Contributor Author

@jamshark70 jamshark70 commented Mar 20, 2020

Here's what I mean by "looks stupid."

(
w = Window("test", Rect(800, 200, 500, 400));
w.layout = VLayout(
	*Array.fill(4, {
		HLayout(
			NumberBox().fixedWidth_(100),
			Slider().orientation_(\horizontal)
		)
	})
);
w.front;
)

ezslider-layout

I'd like to be able to say NumberBox().fixedWidth_(100).fillHeight or something, but this doesn't exist. (We have minHeight_, maxHeight_ and fixedHeight_ but none of these does what is needed.)

@shimpe

This comment has been minimized.

Copy link
Contributor

@shimpe shimpe commented Mar 20, 2020

Some more funny behaviour:

// the following looks less stupid but it does something I didn't expect
// and probably not what you wanted
(
w = Window("test", Rect(800, 200, 500, 400));
w.layout = VLayout(
	*Array.fill(4, {
		HLayout(
			VLayout([NumberBox().fixedWidth_(100), stretch:1]),
			Slider().orientation_(\horizontal)
		)
	})
);
w.front;
)

Screenshot_20200320_083506

@jamshark70

This comment has been minimized.

Copy link
Contributor Author

@jamshark70 jamshark70 commented Mar 20, 2020

Some more funny behaviour:

That's an improvement, though the empty space looks awkward.

Tbh, it may not be an improvement to have a 50-px tall number box with 12 pixel text in it.

@eleses

This comment has been minimized.

Copy link
Contributor

@eleses eleses commented Mar 21, 2020

Just a note here that EZSlider has "special juju" when you double click its label: it turns into Spec edit mode. In general, if you "steal" its components into some other view than that it was created with, that spec-edit-mode stops working (I guess it's because it assumes FlowLayout and tries to replace objects in that). If you want 100% backwards compat, you'd have to make that work too.

@jamshark70

This comment has been minimized.

Copy link
Contributor Author

@jamshark70 jamshark70 commented Mar 22, 2020

when you double click its label: it turns into Spec edit mode. In general, if you "steal" its components into some other view than that it was created with, that spec-edit-mode stops working...

I'd not recommend stealing views into layouts. (I realize you arrived at that approach on the forum for some uses, and that's fine for an individual hack, but I wouldn't do it in the main class library.) It would be better to build the views in a sensible Layout and completely bypass FlowLayout if a Qt layout is being used.

It would be tricky to get both to work in the same class, so Nathan might be right that it would be better to have alternate classes for layout support.

Once you do that, then StackLayout is perfect for switching modes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.