Can a widget automatically set its size?

[YaronCT]

Hi,

I've started this discussion in private with Lukas, and we've thought others may find interest in this. Here's the history of our discussion:

yaronct:

I understand how a widget's area can be determined using the unified dimension system. But what can I do when I don't want to determine the widget's area using the unified dimension system, but let it automatically set its size using some logic from its content? For example, say I have a "StaticText" widget. The natural thing for me to do is make it automatically set its height to the text height plus the frame height, and its width to the text width plus the frame width. Then I'd only say, e.g., I want it at the center of the screen, and it would automatically compute its area. Do u know if this is possible? I'm sorry if there's something basic I'm missing here, I'm still a CEGUI newbie, after all...

Ident:

StaticText cannot size itself depending on its content.
It would also be non-trivial to extend it to do so in an optimal and always perfect way considering all corner-cases, think of word wrapping and other issues for example.
You might be able to determine the size required for the text and adapt the size of the widget depending on that. However, the LNF also introduces margins etc. It would require a lot of extra steps to calculate the final size considering all LNF related dimensions that come into play. In any case, if you can access the Strings required dimensions you can estimate a lower bound for the required size which should suffice. You should be able figure out how to get the size of the text if you look at how the scrollbar (horizontal for example) of the StaticText has this computed. After all, the size must be known there, otherwise we couldnt't scroll it. I dont know anything about the internals in that area.

yaronct:

Err... "LNF" is... ?

Ident:

look n' feel, the skin, as defined in XML

yaronct:

I came to think about it when I ran the sample browser on Android. The text looked very small, so I had to use a larger font. But then the "StaticText" widget didn't get any bigger, and the text was trimmed, both horizontally and vertically. Then I started thinking perhaps it would be best if a widget could adjust its area automatically. And the problem isn't specific to Android - what if the user could change the font in the app configuration. He wouldn't want the text to be trimmed! Actually this happens to me in many applications and is very annoying.

So what do u think about the possibility of adding such an option (perhaps by myself)? There may be technical difficulties (I've looked a bit at how LNF works...), I know, but what do u think about it in general? It seems to me like a very important feature. Of course, we'll have to decide first what exactly it should support - the most basic thing I think for a start is to make it possible for a single-line "StaticText" widget to adjust its height according to the font height and frame height.

Ident:

I think it is a great idea to add this and it has been demanded before.

You would have to check thoroughly by adding Unit tests and making informal tests yourself (FrameWindow might be good for this) that no infinite loops or other issues occur (horizontal + vertical auto size may conflict with wordwrap jumping back and forth from new-line to no new-line, i could imagine). Also: should this only work for widget-internal sizing or also for child-parent related sizing, aka. a parent should be sized whenever a child exceeds it. The latter could pose an even bigger issue to implement imo. Without the latter, however, the auto-resized child might suddenly exceed the parent and be cut off there. This could easily happen in your example. Maybe a maximum size would help here - windows already have that. If wordwrap is on it would then automatically resize vertically.

In any case, I would prefer to continue the discussion in the forum. I am definitely in favour of adding such a feature. Clearly we could only do this in v0 or default. Any further discussion must be made in the forum though.

I dont know about the LNF sizes of frames and margins, but somewhere CEGUI must internally be retrieving those things already anyways, so there might be some ready functionality to retrieve the necessary dimensions directly - or not - I didnt work with this part of CEGUI yet.

[Ident]

Have you planned out an interface for this already ? Should there be properties for this, and if yes which? What functions do you want to provide?
I think it would be good to plan this out before starting to work on it. We must know what features we want before implementing them, and those would best be discussed as well.

Also have you looked into how the text dimensions in the StaticText are retrieved for the scrollbar-related functionality? This should be a good starting point for further calculations.

[YaronCT]

Does a "StaticText" widget support word wrapping? Currently when the text is too long, it's simply trimmed. I want it to be automatically b split to several lines in word boundaries.

[Ident]

Yes. it does: http://static.cegui.org.uk/docs/0.8.4/n ... b8b0b6fe5b
EDIT: Fixed the link for 0.8

[YaronCT]

I suggest to add 2 new boolean properties called "AutoWidth" and "AutoHeight". When set to "false", the behavior would be as it is now - the size is determined by the "Size", "MinSize", "MaxSize", "AspectMode" and "AspectRatio" properties. When set to "true", the corresponding width/height of the "Size" property would be ignored, and the width/height of the window would be determined automatically using some logic (which may vary according to the type of window). The "MinSize" and "MaxSize" properties would still b honored. As for the "AspectMode" and "AspectRatio" properties: If "AspectMode" is set to "Shrink" or "Expand" and exactly 1 of "AutoWidth" and "AutoHeight" is set to "true", the other 1 (which is set to false) would be computed automatically. E.g. if "AutoWidth" is set to "true", "AutoHeight" is set to "false", and "AspectMode" is set to "Shrink"/"Expand", then the height would be computed automatically from the width and the "AspectRatio". In such a case "Shrink" and "Expand" are equivalent. If both "AutoWidth" and "AutoHeight" are set to "true", "AspectMode" and "AspectRatio" would b ignored.

I'm thinking to start by implementing it only for a "StaticText" widget. The width/height of the widget would be determined automatically so that the area that contains the text would have exactly the width/height of the text. The only case where it's not obvious what this means is when word wrapping is on and both "AutoWidth" and "AutoHeight" are set to "true". In this case I suggest that the size of the widget would be determined so that the text isn't trimmed, the size is minimal, and its aspect ratio is equal to the value of its "AspectRatio" property.

[YaronCT]

Just want to add: the properties "HorizontalAlignment" and "VerticalAlignment" would also still b honored.

[Ident]

AutoWidth and AutoHeight - could be very easily confused with the AspectMode & AspectRatio functionality. I suggest using something Text related instead. There must be clear distinction, even if the name gets long.

Also you say AutoWidth and AutoHeight are dominant over AspectMode if both are true. I agree with that decision, this all of course needs to be very well documented since there is no intuitive expectation that can be made about this.

Otherwise this seems good and you clearly have thought this through regarding the AspectMode stuff.

Does AutoWidth and AutoHeight always maximize its size? Aka., does it size the window to the point where all text can be displayed in as few lines as possible and showing all lines vertically using the minimum size possible while doing so? I don't see another opion for this that would make sense. So maybe the option should be called something tgar means "AutoWidthFittingText".

Whatabout minimum and maximum sizes of the widget? Will they be respected or ignored?
Will the window be resized on every change of the Text property?

[YaronCT]

Ident:

AutoWidth and AutoHeight - could be very easily confused with the AspectMode & AspectRatio functionality. I suggest using something Text related instead. There must be clear distinction, even if the name gets long.

I prefer not to use something text related because I prefer the attributes to be more general - perhaps they'll also b meaningful to other types of widgets. I still need to look into that. So I'd suggest the names "AdjustWidthToContent" and "AdjustHeightToContent".

Does AutoWidth and AutoHeight always maximize its size? Aka., does it size the window to the point where all text can be displayed in as few lines as possible and showing all lines vertically using the minimum size possible while doing so? I don't see another opion for this that would make sense. So maybe the option should be called something tgar means "AutoWidthFittingText".

Yes, I meant that the widget adjusts its size so that all text exactly fits in. If word wrapping is turned on - that also means to determine the number of lines automatically.

Actually there's another option that I had thought about but had forgotten: let the CEGUI user fix the number of text lines to some value. Say, add a property named "NumOfTextLines". By default it'll be set to "auto" - which would mean the number of text lines is not fixed but flexible. If, however, "NumOfTextLines" is set to a number (non-negative integer) - that would mean the number of text lines has to be fixed to that value. "AdjustHeightToContent" would still be meaningful - it would take the font height into consideration. The most useful value for "NumOfTextLines" (beside "auto") would be "1" - meaning a single-line text widget, where in combination with "AdjustHeightToContent" set to true - would adjust the widget's height according to the font's height (and widget frame etc.)

Whatabout minimum and maximum sizes of the widget? Will they be respected or ignored?

As I've said, they'll still b honored.

Will the window be resized on every change of the Text property?

Yes. Note, however, that the height of the area reserved for text will b computed according to the font's height, not the text's height. So if, e.g., "NumOfTextLines" is set to 1, and "AdjustHeightToContext" is set to true, then the height of the widget will remain constant even if the text changes - but may change if the font changes.

We can also add a method "Window::adjustSizeToContext(bool adjustWidth, bool adjustHeight)" that will do the size adjustment on a one-time basis, even if "AdjustWidthToContent" and "AdjustHeightToContext" are set to false.

[Ident]

Have you implemented anything so far? I would recommend starting with a prototype that works for basic settings and options and has been heavily tested by you for bugs. Once this works flawlessly and is tested well I would start adding support for multiple settings and checking for corner cases there. We already have a lot of additional settings that influence the way this would work and also we have a lot of corner cases that are introduced in this context so I would definitely not try to do all at once. Will you make a PR for this? I assume we need to target default branch for this, or can this be done with ABI compatibility? (properties typically are stored as class members)

Regarding the "...ToContent" vs "...ToText", I like your suggestion with "...ToContent", I just wanted another keyword that shows that there is "something" we adjust to that is not just some autoscale property, so this sounds a good

[YaronCT]

I didn't start working on it at all. I'm currently working on the Android support on the "v0-8" branch, specifically the Ogre renderer. Of course when any1 (prolly me) implements it it's prolly best to start simple. And if it'll b me of course I'll open a PR for this.

As for which branch it should go to - We'll c. I usually start targeting the ABI compatible brunch, and switch to the API compatible 1 only if necessary, and to the API incompatible branch only if necessary. Is there any problem with adding properties but not as fields? If not, there's still a chance it'll go to the ABI compatible branch.

[Ident]

Like I said, all properties are stored as member variables. This is done for efficiency, otherwise a lot of conversions are necessary as it is the case with all properties defined in the skin (LNF or looknfeel)

You could implement it as part of the "user" properties in v0-8 and do it "right", as a member, in v0

[YaronCT]

Ident: What do u mean by "user" properties?

[Ident]

EDIT: Updated the post for clarity

Sorry, it is called "user string".

in Window.h :

Code: Select all

Window::setUserString(const String& name, const String& value)

Actually CEGUI's PropertyDefinition always (the one used in look n' feel (LNF) files) uses this to store the properties for a window. Imo, this is also the main use-case for this functionality - Any properties that are not part of a C++ class but defined elsewhere, such as in LNF or, like suggested, by a user in their own code, are intended to be stored this way.

Due to String conversions this is way slower than storing them as native type, e.g. as a member in the widget class.

[YaronCT]

But what's the problem with storing it as properties in branch "v0-8"? Why wouldn't it be ABI compatible?

[Ident]

Regular properties are stored as members. Member variables make the size of the instances of the class (in this case a widget class) larger. In ABI branch we can't do anything that changes the size of objects, as you know.

Or what did you mean? I think we have a misunderstanding here. Adding properties is possible but only via user strings, not as member variables. You could do it as user string in v0-8 and then do it properly in default or even v0.