size 0


20-09-2007 14:47:51

A while ago we talked about using 0 as a special value, when calling size functions (setting a widget height or weight to its »natural« size, if there is any). Can't find the old postings. Probably hidden in some other, unrelated thread.

Has that been implemented yet? I can't find anything about it in the source.


20-09-2007 17:05:25

It's not implemented yet, but I have not forgotten! :)

It's a really convenient feature, and on my TODO list. Not sure if I will tackle it before or after Borders. It's not hard to implement, but I need to consider what widgets should support it.

Label - auto size width and height
TitleBar - by default should support auto height. (Users don't create TitleBars)
TextBox - height

And eventually the MultiLineLabel and MultiLineTextBox, which aren't implemented yet.

Am I missing any widgets where this would be useful?


20-09-2007 17:10:57

Image maybe? Size of the texture, that is used to display the image?


20-09-2007 17:24:59

Ah, good one!


21-09-2007 10:33:27

don't forget the buttons. they look better if they are unstreched.

for the buttons the best way to construct them is that they are sampled by 3 images (left side, a small and sizeable middle part and right side) but the implementation can have a bit more workload.

an easy and better way can the use of 2 or 3 defined image sizes for button be.
a small == 100*45
a medium == 150*45
a large one) == 200*45

think of it... :)


21-09-2007 12:40:42

This proposal highlights an interesting problem. A button is a label and an image. What will be its natural size? The size of the texture or the size of the text?
Having auto-sizing according to the button label would be convenient. But on the other hand, a button does not need to have text at all. It could as well contain an image instead.


21-09-2007 13:05:24

you are right. imho the size must come from the texture not from the text.
if the button chooses the width / height automatically by calculating the size of the text would be great. but this can be a feature in version 1.5 or higher :)


21-09-2007 13:11:33

Well, when we have text-based auto-sizing for labels, then we will have text-base auto-sizing for buttons. No need to wait for a later version. What we need is a way to select one of these modes automatically.

Maybe textture-based auto-size, if the button's string is empty, and text-based auto-size, if it is not empty?


21-09-2007 14:53:47

sounds good. but if you create a button then there is alwas the texture first so that it dosen't make sense for them. or i am wrong?


21-09-2007 15:05:50

True, not only for buttons, but for labels too. We already have a lot of create methods. Adding more to create an initial text wouldn't be a good idea (besides we would get problems with overloading).

But the natural size can still be applied when changing the size of the widget later


21-09-2007 17:16:07

Yah, I ran into this problem in my mind yesterday, after you mentioned the Image. We now have a widget that can be sized according to texture and text, and no way to be able to support them all upon creation.

Regarding stretching of the button, you are right, the current buttons aren't as nice as they could be. When I implement borders this should help some. I have also thought up a plan to implement texture tiling in the future, but not sure how easy that will be.

We could make '-1' auto size to texture dimensions, and then have function like:

matchTextDimensions(bool matchCaptionLength, bool matchGlyphHeight);
matchTextureDimensions(bool match);

It would take some work to manage the different auto size options, and the '-1' and '0' would need to be documented. It's tough supporting both of these convenience methods. I would say make it simple and only support sizing to text. You can get texture pixel dimensions easy enough. :P


21-09-2007 18:00:46

that is a good plan...

for the lazy one on documenting this...

implement both methods:
1. the auto method by 0 or -1
2. export those function too

i always write the default parameters and their behavior into the methode documentation header. (atm there you can always read (has to be supported by al widges' or so) there is the right place for (0 == autosize match the dimenson of....)



21-09-2007 18:32:18

Don't know The whole thing is getting rather complex. Maybe going only for text auto-sizing is the better option. Or forget completely about default-size and add separate methods for resizing to natural size (both text and texture). Tough decision.

Regarding the auto-sizing of text: I would prefer, if you could use the maximum height of the font instead of the maximum height of the characters in the displayed text. Its probably more useful and would allow making use of the default-size even in the create method (Label and such).


21-09-2007 18:39:18

Yah, would it be acceptable to only push for the auto size to text functionality?

Regarding auto sizing height, all glyphs have the same height, within a given Ogre::Font texture. :wink:


21-09-2007 18:52:48

Yah, would it be acceptable to only push for the auto size to text functionality?

For me, yes. As you wrote, the natural size for a texture is easy to get hold of.

Regarding auto sizing height, all glyphs have the same height, within a given Ogre::Font texture. :wink:

Good to know.