QGUI_GMM_RELATIVE deprecated?

I am considering removing use of QGUI_GMM_RELATIVE. I have noticed through using and building the demo that GUI's look much better when planned out using Pixel coordinates. I want to make QGUI_GMM_PIXELS the default values for use, but still keep QGUI_GMM_ABSOLUTE, for situations where you want to specify components in values relative to the viewport width/height. This also reduces an additional step taken for conversions, since under the hood, Quads are rendered in Absolute coordinates. Setting pixel/absolute positions will still be relative to the parent widgets origin, but sizes will be according to the viewport dimensions.

If this doesn't have a large impact on users, which I hope it doesn't, I will remove it and make pixel values the default choice. I want to remove it for cleanliness, clarity, and generally improved aesthetic value.

I voted »yes, I use it all the time«. QGUI_GMM_RELATIVE is an important layout tool for me, while I have absolute no use for QGUI_GMM_ABSOLUTE. But actually I could do without QGUI_GMM_RELATIVE, if you really want to get rid of it.
A large part of my GUI is using a mix of relative and pixels and these parts need to be reformatted at a screen resolution change anyway. For the few pure relative windows/panels, I could add some reformatting code too. Its not trivial, but not a huge problem either (though it certainly would make the code look a bit more complicated).
If I understand you correctly you not only want to remove relative as an option for setting/getting size/position, but also change the internal implementation from relative to pixels. Some of my GUI components would actually benefit from it, since I could change the size of windows with pixel layout without the need to re-position every single widget.
To come to a conclusion, I am totally in favour of storing size and position information in pixels instead of relative values. I would prefer to keep the option to read/write the relative size and position, but I can life without it.

Edit: To make this more clear: "read/write the relative size and position" means the current size and position relative to the current size of the parent. These values could be easily calculated, but it would be nice to have an interface for specifying these values explicitly instead.

Awesome, that is good to hear! When it comes down to it, a Quad is rendered in Absolute values. [0-1] for top, left, right, and bottom. Whenever a user sets a width/height/position etc using one of the GuiMetricsMode types, it is first broken down into relative coordinates, and from that the absolute and pixel dimensions are derived. There are some changes I plan on making in the future, and this would pretty much make using relative useless. The purpose of relative was to be able to maintain a set position/size in relation to the parent widget. But now I'm finding I don't want this behavior.

For version 0.9.8, I will implement Horizontal and Vertical Anchoring. This means that you can resize widgets, lets say a window, and the labels inside it can stay a certain pixel/absolute distance from the top or bottom and left or right side of the window.

Tonight I am going to implement the following properties of Widgets:

bool mMaintainRelativeWidth; // default false
bool mMaintainRelativeHeight; // default false

(getters and setters of course!)

In certain situations like menu's or TitleBar, you want them to always be the same width as the parent. Not true for the Height.. I can't really find any good examples for that one, but its added for consistency and for unknown cases that will arise.

So with anchoring and the 2 properties above, we no longer need to have QGUI_GMM_RELATIVE at all. I was worried it would affect you a lot, but I'm glad to hear this is an acceptable change.

Anchoring souinds good.

Any change, that I can convince you to remove QGUI_GMM_ABSOLUTE too? After all, the viewport size is equal the sheet size, right? So you can work around a missing QGUI_GMM_ABSOLUTE almost as easily as for a missing QGUI_GMM_RELATIVE. It would remove 1-2 arguments from a lot of methods and make the whole interface a lot more compact.

That's definately true. You know, I had a thought about Menu's, and that having to specify them to be full width of their parent (or not, its up to the user) would be a pain. But then, I had a great idea. AutoSizeWidth for Menu Widget!!! Using a width of 0 when creating a Menu makes it have the same width of the parent. (this can be applied to TitleBar as well, although it doesn't matter, since Users don't directly create TitleBars)

Ok, so this does sound like a good idea. Lets try to think up any downsides to this change. We would be using only pixels for everything. This would definately make things a lot more clean and direct.

The only downside I can see is another API breaking change. But if we have to do it, then doing it now is better than doing it later.

Regarding the 0, I am not sure, if thats something we really need. Anchoring affects position as well as size, right? (maybe independently from each other?)
So we could simpy set a menu item to the same width as the menu (probably ignoring the create-method's wiidth argument and using the menu's width automatically instead) and then anchor it.

I have to make sure to be careful with the mMaintainRelativeWidth/Height and AutoSize functionality, as those two are conflicting.

If MaintainRelativeWidth is set true, AutoSizeWidth will be set false. And vice versa. The difference is that MaintainRelativeWidth is directly related to the parent's dimensions, and autoSizeWidth works using an implementation specific to the widget. In the case of the Menu, both function the same, which adds to confusion. I don't think it's a problem, I just have to make sure these widgets with Autosize functionality don't interfere with support for the MaintainRelative functionality.

[edit] Ah, good point. I was thinking of having anchoring only for position, but it could also be used for sizing. How will anchoring work with AutoSized lables? Its fine if the anchor is only on one side, but if, for example, an auto sized label has an anchor to both the left and right side of its parent, it can no longer have its width auto sized. What I'm thinking is that anchoring is a replacement for my "maintainRelativeWidth/Height" variables. I don't see any problems (I think), just bringing this up in case you find something I missed. [/edit]

I am not really sure about this auto-sizing feature. When I proposed auto-sizing for labels, I thought about setting the size once according to the currently contained text.
What good would be a Label that changes its size, whenever its contents changes? Putting it in a regular window, would be only of limited use, because it could easily blast the layout of that window. And you cant use it for a menu-item either. Within a menu all items must have the same width, so the items can't auto-size on their own.

The only real use for it is that when you create a Label, the text is "". You then can set the text, and the font, since it is using a default font. We want it to maintain dimensions around the text, whatever it is (because we don't know at time of creation), and whatever font is being used (because it it likely to change).

Also, I like this feature for Lists, in terms of height. If you add/remove ListItems, the list will grow/shrink. If the list is a set size, then the list would not grow, but the ScrollPane would do all the work.

Label:
AutoSizeHeight: can be set on or after creation, and causes Label to maintain the height of the Glyphs within the Text object.
AutoSizeWidth: can be set on or after creation, and causes Label to maintain the width of the Caption of the Text object.

List:
AutoSizeHeight: can be set on or after creation, and causes Height to increase/decrease when adding/removing ListItems.

Menu:
AutoSizeWidth: can be set on or after creation, and causes menu to maintain the same width as its parent.

TextBox:
AutoSizeHeight: can be set on or after creation, and causes TextBox to maintain the height of the Glyphs within the Text Object.

virtual Widget::setHorizontalAnchor(Widget::HorizontalAnchor a);
virtual Widget::setVerticalAnchor(Widget::VerticalAnchor a);

enum HorizontalAnchor
{
ANCHOR_LEFT,
ANCHOR_RIGHT,
ANCHOR_NONE,
ANCHOR_LEFT_RIGHT
};

enum VerticalAnchor
{
ANCHOR_TOP,
ANCHOR_BOTTOM,
ANCHOR_NONE,
ANCHOR_TOP_BOTTOM
};

Default Anchors are ANCHOR_LEFT and ANCHOR_TOP.

Certain Widgets with auto size will override the the setHorizontalAnchor/setVerticalAnchor functions. If anchor is LEFT_RIGHT or TOP_BOTTOM, this will override any autoSize and set autoSize false. Likewise, if AutoSize is set, the Anchors will be set to default LEFT and TOP.

Is this a bad idea? I'm willing to try this out at least, and see if we think it will be a good idea in practice or not.

Looks mostly good, though I think you are overdoing it with the auto-sizing

I see your point when it comes to widget, that are a composition of other widgtes (like a list).

But when it comes to autonomous widgets (like a label) it looks like a lot of additional complexity for very little benefit. After all, when the text or the font of a label is changed, the code that makes the change knows about it and can easily call a resize-method. The only thing auto-sizing is doing here, is to avoid this single call.

If you would limit auto-sizing to the first case (compositions) you could simplify the interaction between auto-sizing and anchoring, because in these cases it make sence for auto-sizing to always take priority over anchoring.

Nobody has polled, so I'm going to go ahead and keep working to get rid of the absolute/relative usage.

I was able to get it compiled without errors yesterday, but now I have to go in and fix all the logic errors, since I was using a lot of relative values (0.0 to 1.0) which now should be in pixel values. The up side is that the management of dimensions is easier, and the API is cleaner. I'm not used to setting widget positions on a pixel basis, but in the future I don't plan on writing out all my personal layouts in pixels anyway. (I'll have an editor do that for me )

I have made the change, only pixels are used! The new version is really easy to use now, aside from positioning using pixel values. Not that it was easy positioning widgets with relative or absolute values either.

I need to redo Scrolling to work with all the changes I've made, and I'll probably add in Anchoring. I'll commit to SVN after Scrolling is finished, and update the SVN page.

I'm really happy about these new changes.