[PATCH] Permit setting a max size on relationally-sized GUI Objects

[s0600204]

The attached patch adds a max_size attribute to GUI objects. This permits GUI designers to set an upper limit on the size of a GUI object that have a relational size.

As an example, currently when opened the structree takes up the entirety of the screen real-estate. Whilst this makes sense on lower resolution screens, on larger resolution monitors this leaves a lot of unused space within the gui page.

With this patch, the structree will still take up the entire width on lower-resolutioned monitors (where a scrollbar would be useful), but grow no larger than needed to display the entire tree without (for now, imaginary) scrollbars on larger-resolutioned monitors. (​http://imgur.com/a/buTvg)

By default, the max_size is set as 0 0 100% 100%, and if not modified from such will/should be ignored when calculating the object's displayed size.

[s0600204]

Proposed patch

[Vladislav Belov]

Should it has min_size too? I think it's more relevant than max size for some labels or something else. Also draw.js:230: let page_maxsize, why it's not in lower camel case as other variables above (even not page_max_size)?

[elexis]

Moving to the new WIP milestone.

[Vladislav Belov]

Also, I think, better to move the default size GUI<CClientArea>::SetSetting(this, "size_max", CClientArea("0 0 100% 100%")); from CTooltip.cpp to IGUIObject.cpp, else you should set default size_max for every element type (input, text, button, etc).

[s0600204]

Should it has min_size too?

Might be a good idea, but would need some decisions made about how such a thing should work.

For instance, setting a max_size on an object also imposes a maximum size of any relationally-sized children of that object. This works automatically due to how sizing in the gui system works.

If a min_size is set on an object, should that also prevent the parent (and the parent of the parent, and so on) from getting any smaller than that? What should happen if there are two (or more) siblings with a min_size? Should the parent be prevented from shrinking below the largest of the min_size of its children? Or perhaps a sum of relevant derived values from the min_sizes of all its children? And how would this be fetched? This would require a rethink of how the gui system handles sizes.

Either way, this ticket is for max_size and implementing a min_size is beyond the scope of this ticket.

[...] better to move the default size [...] from CTooltip.cpp to IGUIObject.cpp

The defaults for all objects are set in xml, via the default style found in either gui/common/styles.xml or gui/common/modern/styles.xml. This style is applied to all UI elements before any custom style (set by the style attribute on the object) is applied.

Or more accurately, the style is applied to all UI elements *except* tooltips (and scrollbars) (the comments in the mentioned style.xml files should probably be updated to reflect this). The styling for tooltips are set within setup.xml files, and for some reason although there does exist a setup/style with the name default (in gui/common/modern/style.xml), this is not actually used as a default. Thus, everytime a tooltip is defined/setup, it would require a size_max attribute to be set.

However, this attribute will always be the same - 0 0 100% 100%. Why? Because there's no call to limit the maximum size of the tooltip in this way. Tooltips that appear next to the cursor cannot be actually touched by the cursor (as the tooltip tracks with the cursor) and thus the use of scrollbars on a tooltip's textual content is pointless and so, by extension, is limiting the absolute size. As for tooltips that have their content appear in a different ui element - that different ui element has its own size and max_size attributes.

Tooltips do already possess a maxwidth attribute which limits the width of the tooltip, forcing it to just get taller and taller. And in case you're curious, replacing maxwidth with max_size is not a viable suggestion. (maxwidth is a width value; all size and max_size attributes define two x and two y values relative to the parent object (which for tooltips is the game window))

So setting a default for max_size in CToolTip.cpp actually does make sense, although as there doesn't seem to be a reason to ever change it, it should really be a constant - but the gui settings don't allow 'locking' a setting so it can never be changed.

[Vladislav Belov]

Replying to s0600204:

For instance, setting a max_size on an object also imposes a maximum size of any relationally-sized children of that object. This works automatically due to how sizing in the gui system works. If a min_size is set on an object, should that also prevent the parent (and the parent of the parent, and so on) from getting any smaller than that? What should happen if there are two (or more) siblings with a min_size? Should the parent be prevented from shrinking below the largest of the min_size of its children? Or perhaps a sum of relevant derived values from the min_sizes of all its children? And how would this be fetched? This would require a rethink of how the gui system handles sizes.

No, size_min and size_max should work the same and shouldn't affect a parent or/and a child, it works automatically. Or your patch is wrong, because size_max doesn't affect on childs size. We have the clear relationship system, so just use it.

Or more accurately, the style is applied to all UI elements *except* tooltips (and scrollbars) (the comments in the mentioned style.xml files should probably be updated to reflect this). The styling for tooltips are set within setup.xml files, and for some reason although there does exist a setup/style with the name default (in gui/common/modern/style.xml), this is not actually used as a default. Thus, everytime a tooltip is defined/setup, it would require a size_max attribute to be set.

We should avoid hard-coded values for specific elements, it's a little bit hacky, so you need to set it for the base class, or improve tooltips to use default style, instead of this hack.

Also why CRect client = this->GetClientArea(parent); instead of CRect client = GetClientArea(parent);, do you have another GetClientArea?

[s0600204]

Replying to vladislavbelov:

No, size_min and size_max should work the same

Perhaps, I'm just saying that it needs some decisions made about the specifics of how to implement it as the current gui sizing system doesn't support restricting a parents size dependant on the size of child elements and that might be an issue.

and shouldn't affect a parent or/and a child,

Yes they should, and in fact do - that's why a child doesn't get any bigger when its parent stops growing

This works automatically due to how sizing in the gui system works.

it works automatically.

That's what I said. You even quoted it.

Or your patch is wrong, because size_max doesn't affect on childs size.

It does if the child is relationally sized - its size is relational to its parent's size. It might not effect or alter it directly, but it does result in a limitation to the size which is, in itself, an effect.

We have the clear relationship system, so just use it.

I am

To be honest, I think there's been some misunderstanding somewhere. And frankly, min_size is outside the scope of this ticket. Could we concentrate on max_size, please.

We should avoid hard-coded values for specific elements, it's a little bit hacky, so you need to set it for the base class, or improve tooltips to use default style, instead of this hack.

Modifying the gui system to cause tooltips to use the default style is outside the scope of this ticket. Feel free to create a new ticket for that.

It's not hard-coded - it can still be overridden by setting max_size inside a tooltip's <setup> xml definition; I was pointing out the chances of someone actually wanting to do this is low as the result is undesirable.

Also why CRect client = this->GetClientArea(parent); instead of CRect client = GetClientArea(parent);, do you have another GetClientArea?

That also appears to work. (I think I was trying to be less ambiguous in scope.) Thank you.

[Vladislav Belov]

Replying to s0600204:

Perhaps, I'm just saying that it needs some decisions made about the specifics of how to implement it as the current gui sizing system doesn't support restricting a parents size dependant on the size of child elements and that might be an issue. To be honest, I think there's been some misunderstanding somewhere. And frankly, min_size is outside the scope of this ticket. Could we concentrate on max_size, please.

Ok, probably there will be a ticket.

Modifying the gui system to cause tooltips to use the default style is outside the scope of this ticket. Feel free to create a new ticket for that.

IMHO, you're adding a property with the default max size for all elements, but for the one object you set in the CPP part, and for others in styles, looks strange.

It's not hard-coded - it can still be overridden by setting max_size inside a tooltip's <setup> xml definition; I was pointing out the chances of someone actually wanting to do this is low as the result is undesirable.

It's hard-coded, because nobody (i.e. modders, they need to download sources) don't know what's the size_max of tooltips, and couldn't change that for all tooltips.

[Vladislav Belov]

At least I suggest you to add something like TODO: move to the styles to CTooltip.cpp.

[s0600204]

Replying to vladislavbelov:

IMHO, you're adding a property with the default max size for all elements, but for the one object you set in the CPP part, and for others in styles, looks strange.

It's hard-coded, because nobody (i.e. modders, they need to download sources) don't know what's the size_max of tooltips, and couldn't change that for all tooltips.

Ok, I see your point (I think). However moving it to IGUIObject.cpp as you initally suggested doesn't solve that.

As max_size isn't very useful when it comes to tooltips, IMHO it would be nice if we could suppress or remove the attribute for tooltips (and only for tooltips). Unfortunately, RemoveSetting() is not something that appears to exist, and besides that would cause problems elsewhere.

Replying to vladislavbelov:

At least I suggest you to add something like TODO: move to the styles to CTooltip.cpp.

I'm sure elexis would be thrilled with another todo in the code ;)

...

This might not be a sane idea (it's been a long day and I may not be thinking clearly) but what if I removed the line from the proposed patch where I set a default max_size within CTooltip.cpp, and modify GetClientArea() to check if the value of max_size is the same as a new CClientArea (which is equivalent to a 0 x 0 box) and just return client in that case? Designers would still be able to set a max_size in <setup> if they really want to (causing a potentially undesirable visual state) but at least we wouldn't be setting a default in cpp.

[Imarok]

Move tickets to their correct component.