That's the minimum size, not the 'optimum' size. An 'optimum' size can only be input by the user, not determined by the widget itself.
'Optimum' means 'most optimized' in this case, which is usually the smallest size that doesn't affect the widget's functionality.
Another example of optimum size, is the width of an line input widget with a set maximum of characters.
You mean a minimum number of characters, and I already talked about this case, in my previous post.
This optimum size is dynamic, and can change while the app is running (button caption changes, for example). Min and max sizes are usually static (unless the user explicitly changes them).
Exactly. So, with my algorithm, when the caption of a button is changed, it will trigger the recalculation of all the dialog items, but only when it is required.
I think there's not really much here to argue. That is, I don't think any of you are actually disagreeing on any high level concepts... Practically speaking, the widget's true minimal drawing size is irrelevant to the programmer. Say I have a container with 100 pixels of space. I want to draw a button in there that I assign a minimal size of 150 pixels. The actual minimal size is, say, 30 pixels. So technically the button could fit in that 100 pixels of space.However, I've declared the minimum size to be 150 pixels. Thus the button should be drawn internally at 150 pixels but cropped to 100 when it goes into the parent container. It's my own fault if that wasn't my intention. If I wanted the button to fill the entire container, I'd simply not specify any min/max constraints on it. Its "optimal" values are largely irrelevant, especially if the GUI theme has the ability to draw widgets of any size or scale.
I think you have it a little backwards. A widget should really size itself to the minimum size that doesn't affect its operation, so as that the GUI leaves as much as possible useful work area to the user.
Take a button with text, for example: a button should show its whole text, otherwise it is not usable. So, the only thing a button should be required to do is to size itself according to its text and font that uses at the specific state (enabled, disabled, selected etc).
Now, if you want the button to be big and fill its parent container, the best approach is not to do it by the button itself, but with the parent container: it should be the parent container that decides how the button is ultimately sized.
This is the most flexible approach, because it allows children widgets to have the mimimum possible size, unless their parent says otherwise.
In the case of buttons, for example, with this technique, you can make button containers that:
size the buttons equally both vertically and horizontally, and places them into a row or column. For example, the buttons of a dialog box.
wrap itself around the button; for example, adding a resizing border.
resize the button to a specific size.
resize the button to expand itself to the available space left by its parent.