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:
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...
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.
Err... "LNF" is... ?
look n' feel, the skin, as defined in XML
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.
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.