Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » GWEN UI Allegro5 port

This thread is locked; no one can reply to it. rss feed Print
 1   2   3 
GWEN UI Allegro5 port
Matthew Leverton
Supreme Loser
January 1999
avatar

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
avatar

Matthew Leverton
Supreme Loser
January 1999
avatar

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
avatar

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) :-X

append:
Now this makes me wonder too if people that are learning Spanish have problems with things like "haber" vs "a ver", usual typing errors here (both are pronounced exactly the same).

axilmar
Member #1,204
April 2001

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.

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:

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.

etc.

Oscar Giner
Member #2,207
April 2002
avatar

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:
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.

axilmar
Member #1,204
April 2001

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
avatar

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>
This doesn't change the essence of the layout algorithm.
</quote>
Did I say something? You take it as is anything anyone says is to go against you. I'm just giving ideas, different ways of doing things.

axilmar
Member #1,204
April 2001

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
avatar

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
avatar

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.

Oscar Giner
Member #2,207
April 2002
avatar

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
avatar

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.

Trent Gamblin
Member #261
April 2000
avatar

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
avatar

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:

  1. the smallest size the widget can possibly draw itself while still being useful

  2. the ideal size the widget should be

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

... 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
avatar

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.

Matthew Leverton
Supreme Loser
January 1999
avatar

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:

  • Create the horizontal layout with two (or more) cells

  • Create the vertical layout with two (or more) cells

  • Add widget #1 into the horizontal slot 0

  • Add vertical layout into the horizontal slot 1

  • Add widget #2 into the vertical slot 0

  • Add widget #3 into the vertical slot 1

  • Set horizontal layout to be parent widget's layout manager

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

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

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
avatar

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
So basically, every layout manager is assigned a number of cells by the user, and then each cell is assigned a widget?

Matthew Leverton
Supreme Loser
January 1999
avatar

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:

  • Horizontal and vertical boxes are as expected.

  • Grids use N = y * w + x

  • Some layouts use constants like ALGUI_NORTH_CELL.

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
avatar

@axilmar
I may have misunderstood what you meant. Did you mean make a set of widgets that are also layout managers? Or did you mean make every widget a layout manager? The first option I can understand, but I thought you were talking about the second option, which seems wrong.

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.

 1   2   3 


Go to: