|
GWEN UI Allegro5 port |
Matthew Leverton
Supreme Loser
January 1999
|
ahh, so many it's=>its failures 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. The only part of sizing that is really important is how to determine to divvy up space among widgets. But as I've described before, even that is pretty easy to do with just a simple "default" or "requested" size. (It may or may not be "optimal," depending on the meaning you attach to that word.) |
Edgar Reynaldo
Major Reynaldo
May 2007
|
Uh... I thought it was "it's" because that is how you specify ownership. I know it is not 'it is', but is it really "its"? My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
Matthew Leverton
Supreme Loser
January 1999
|
The word its belongs with this group: hers, his, its. The word it's is a contraction for it is or it has. |
Oscar Giner
Member #2,207
April 2002
|
I've always wondered why English natives have so many problems with it's/its, there/they're/their... (maybe it's my impression, but it seems to me they're the ones who usually do those mistakes, not counting typos) append: -- |
axilmar
Member #1,204
April 2001
|
Edgar Reynaldo said: 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. Oscar Giner said: 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. Quote: 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. EDIT: Matthew Leverton said: 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:
etc. |
Oscar Giner
Member #2,207
April 2002
|
axilmar said: You mean a minimum number of characters, and I already talked about this case, in my previous post. No, I mean that the number of characters that can be typed has a maximum. For example, a line edit for inputting a year would have a maximum number of characters of 4. So the optimum width would be the needed to display 4 characters (usually, 4 "W" or "M"). Append: -- |
axilmar
Member #1,204
April 2001
|
Oscar Giner said: No, I mean that the number of characters that can be typed has a maximum. For example, a line edit for inputting a year would have a maximum number of characters of 4. So the optimum width would be the needed to display 4 characters. Nope, because if the maximum number of characters was 3000, the optimum width would not be for 3000 characters. You are talking about the minimum number of characters. Quote: In Qt, wisgets don't size themselves to their optimum size, but the have a sizeHint() function that returns this optimum size. So the parent takes full responsibility of sizing. This doesn't change the essence of the layout algorithm. |
Oscar Giner
Member #2,207
April 2002
|
axilmar said: Nope, because if the maximum number of characters was 3000, the optimum width would not be for 3000 characters. You are talking about the minimum number of characters. I'm talking about how Qt does it, and yes, the optimum size is set that way. If the maximum numbers of characters is 3000 then the optimum size will just not be possible to acquire and a smaller size will be set. <quite> -- |
axilmar
Member #1,204
April 2001
|
Oscar Giner said: I'm talking about how Qt does it, and yes, the optimum size is set that way. If the maximum numbers of characters is 3000 then the optimum size will just not be possible to acquire and a smaller size will be set. In your example, the optimum size is the number of characters for a Year, not the maximum characters. Quote: I'm just giving ideas, different ways of doing things. No problem with that, I just wanted to point out that's the end result is the same. |
Matthew Leverton
Supreme Loser
January 1999
|
axilmar said: 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. I call that the "default" size. If you don't care as the programmer, never call the resize method on the widget. It then keeps its default, minimal size. |
Edgar Reynaldo
Major Reynaldo
May 2007
|
axilmar said: 'Optimum' means 'most optimized' in this case, which is usually the smallest size that doesn't affect the widget's functionality. AKA, the minimum size. I call that the minimum size because if it were any smaller it wouldn't function properly. My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
Oscar Giner
Member #2,207
April 2002
|
Edgar Reynaldo said: AKA, the minimum size. I call that the minimum size because if it were any smaller it wouldn't function properly. Take a line edit for example. An optimal size may be such that it can display 10-15 characters. It's minimum size will be the required to display a single character. The optimal size is determined by the widget, the minimal size (in most cases it defaults to the optimal size) can be changed by the user. The actual minimum size of a widget will be MAX(minimum size, optimal size). -- |
Edgar Reynaldo
Major Reynaldo
May 2007
|
The point is, your 'optimum' size is pretty much arbitrary. One user would prefer 10 characters of space available, another would prefer 20. It's better to leave that up to the user, and not try to guess, because you could never make it work as a one size fits all solution. My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
Trent Gamblin
Member #261
April 2000
|
That's kind of the point of layout. The user can resize the window if they want more or less space.
|
Matthew Leverton
Supreme Loser
January 1999
|
Oscar Giner said: Take a line edit for example. An optimal size may be such that it can display 10-15 characters. It's minimum size will be the required to display a single character. I thought non-native speakers didn't make the "it's" mistake. I agree with Edgar on this. Or at least, I understand his disagreement. I don't care what you call it, but there are two distinct concepts:
The smallest possible size is of no concern to the programmer. It's only so the widget doesn't draw something silly looking or divide by zero or some other nonsense. If the visible size is smaller than the minimum size, then the widget can simply be cropped. The ideal size is often arbitrary, and depends on the use case. The programmer must be given a way to change the default size that a widget thinks it should be. You can do it via the layout manager or the widget or some combination. With all the fuss over terminology, I'm not even sure how you all are even suggesting that a programmer gain that control. I chose to use a resize() function that changes the default size. If you don't use a layout manager, then that's what you get. If you resize to 2x2, that's all you'll see on the screen. If it's smaller than the widget's internal minimum size, then the widget will operate internally as if it's its minimum size, but only the 2x2 top left corner will be visible. If you do use a layout, then the requested size is simply used as the initial size on the first pass. It's subject to be made bigger or smaller at the layout's whims. But never does the minimum internal drawing size ever actually play a role in determining how much space the widget gets in a layout. |
axilmar
Member #1,204
April 2001
|
I prefer layout management pretty much the way ML describes it: the resize() method resizes the widget to a specific (width, height) size, but the layout ultimately decides what the actual widget's size will be. |
billyquith
Member #13,534
September 2011
|
Edgar Reynaldo said: ... I have really never understood what a layout manager would actually do. ... It is so that you can position and size your widgets automatically. This can very useful in resizable windows, or where you have to UI designer. You basically choose some rules and the layout class applies them to the child widgets. It is important that the layouts are separate from the widget implementation (i.e. they refer to existing widgets without being part of their implementation). The layout is nothing to do with appearance or function. They are merely helper classes. Separating the layout code easily allows to add lots of different or custom layouts later. |
Edgar Reynaldo
Major Reynaldo
May 2007
|
I'm still not exactly sure how I would integrate a Layout Manager into my current GUI setup. All widgets are derived from a common base, and there is a Widget Handler widget than handles all their input, update, and display routines. Would I give each Widget Handler a pointer to a Layout Manager base that the user can set? How do I handle nested Layout Manager's? Specifically, how do I handle adding widgets to a layout manager that contains another one? Say the first is a horizontal layout widget, and the second cell is another layout manager that is vertical. When I add the second, third, and other widgets to the first layout manager do they all get added to the second cell or do some go to the third horizontal cell? How would I know what to do? Set a limit on the number of cells in the vertical layout manager? I just need some more practical ideas to get my head around how this would all work. My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
Matthew Leverton
Supreme Loser
January 1999
|
My widget hierarchy goes something like: Object -> Widget -> Container. Every Container has exactly one Layout object. By default that object is NullLayout, which does nothing. Widgets can only be added to widgets that derive from the Container widget. Adding a widget directly to a container is just a shortcut for adding it to that container's layout. Thus these are the same: algui_add(parent, widget); algui_add_to_container(parent->container, /*cell number*/ 0, widget); But you must use the second method if you want to specify a cell number to use, so generally the first method is only used when you are using absolute positioning (NullLayout). I allow you to add a layout directly to another layout for nesting purposes. But you could also do it by creating a transparent Container object that is used for no purpose other than sub layouts. In your example you would:
Note that you no longer need to explicitly add a widget to a container widget, because the layout takes care of that. It really doesn't add much complexity, because the layout can implicitly set the widget's parent pointer. i.e., Behind the scenes they can still be owned by the parent widget. Then the layout would kick in and position all of the widgets. Any time you add something to the layout, you would then need to recalculate the widgets. |
axilmar
Member #1,204
April 2001
|
Edgar Reynaldo said: I'm still not exactly sure how I would integrate a Layout Manager into my current GUI setup. It's simple: make each widget a layout manager. Have grid widgets, horizontal box widgets, vertical box widgets, etc. Thus your example becomes really simple: just insert each widget in the widget you want. |
billyquith
Member #13,534
September 2011
|
Edgar Reynaldo said: I'm still not exactly sure how I would integrate a Layout Manager into my current GUI setup. Look at Qt. From memory that is nicely done. If you use the designer you can see how it is all supposed to work. Someone else also cited Java. Have a look there too. As mentioned by other posters, the layout widgets aren't really widgets, they are containers, which contain the widgets they are laying out. So they don't actually have an appearance, like buttons etc, they just do they layout. If you are unable to see how to do this with your current system you'll probably need to put more levels of abstraction in. Again, for guidance, see the Qt docs and hierarchy. |
Edgar Reynaldo
Major Reynaldo
May 2007
|
axilmar said: It's simple: make each widget a layout manager. Have grid widgets, horizontal box widgets, vertical box widgets, etc. Thus your example becomes really simple: just insert each widget in the widget you want. That does not sound like an ideal solution. Maybe if each widget owned a layout manager, maybe, but that is still making the widget base class a container class, which IMO should be separate. @Matthew My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
Matthew Leverton
Supreme Loser
January 1999
|
Edgar Reynaldo said: Maybe if each widget owned a layout manager, maybe, but that is still making the widget base class a container class, which IMO should be separate. Conceptually I agree. However, you may find that singular widget entities that cannot contain children still have multiple hidden children of their own. You may have a push button that accepts an icon widget. Internally, you could use a layout to render that. i.e., Your push button could contain two children: a text label and an icon. It could use a horizontal layout to position things. But since it doesn't extend from your Container class, a programmer couldn't actually add widgets to the button. Those sub widgets would never be seen or heard from, since the button widget would trap the events and re-emit the useful ones as its own. I don't actually do that... but I sort of wish I had designed my GUI that way. Now that I have layouts, I may go back and change it someday. Quote: So basically, every layout manager is assigned a number of cells by the user, and then each cell is assigned a widget? That's what I do. Since I use C and don't have overloading at my disposal, I just have a generic "add widget to cell #N" function. It's up to the container to treat that number appropriately:
For some layouts, it might be useful to have "resize & append" functions. But usually a person knows ahead of time how many cells they need. |
Edgar Reynaldo
Major Reynaldo
May 2007
|
@axilmar My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
jmasterx
Member #11,410
October 2009
|
I think the idea is that any Widget that derives from Container will have layout management capabilities. I personally quite like how Java does Layout management. Agui GUI API -> https://github.com/jmasterx/Agui |
|
|