I have ported the GWEN UI to Allegro 5 . I'm not an expert at unicode so I had a little trouble with the font rendering. It seems to work, but I'm not sure if it is correct. Not quite sure how to convert std::wstring to ALLEGRO_USTR.

Code is here. The is an input header and the other two are the renderer.

http://code.google.com/p/gwen/issues/detail?id=56

GWEN is a very nice UI and it would be nice if it fully worked with Allegro 5:

http://code.google.com/p/gwen/

Perhaps if you know how to fix it you could post the files to the GWEN link above.

Cheers.

Should be simple, something like (untested):

ALLEGRO_USTR *wstring_to_ustr(std::wstring w) {
    ALLEGRO_USTR *u = al_ustr_new("");
    for (int i = 0; i < w.size(); i++) {
        wchar_t wc = w[i];
        al_ustr_append_chr(u, wc);
    }
    return u;
}

Then make sure to free the string later with al_ustr_free.

If looping through all characters is too slow, you could also simply assume that wstring.cstr() is UTF16 under Windows:

ALLEGRO_USTR *wstring_to_ustr(std::wstring w) {
#ifdef ALLEGRO_WINDOWS
    return al_ustr_new_from_utf16(w.c_str());
#else
    return al_ustr_new(w.c_str());
#endif
}

However that's probably a bit hackish as it depends on the exact windows version / exact OS version.

It's called ALTGR because that's what it's called in England. We probably should add a #define.

Right, thanks, will try that. I have Mac keyboard with "alt" on the right. I noticed a Windows/PC keyboard has "Alt Gr" today.

The GWEN guy put a lot of work in it, and the API seems good. However, it has a profound lack of documentation, and I also think it misses layout management (although I am not sure - I saw a 'layout' method somewhere).

As someone who has their own fairly complete GUI library (minus docs and a few widgets), I have really never understood what a layout manager would actually do. Is it like an HTML renderer? Does it position everything according to a set of rules? How could you possibly make it intelligent enough to always reposition everything the way the user wanted it to? In my library, all the positioning and resizing is done by the user themself, because I haven't thought of a good way to do it for them yet.

Edgar: look at Qt's layout system. It's pretty good. Very easy and simple for not very complex layouts, but very powerful to allow very complex layouts. I still haven't come with a layout design that it can't handle. You can even inherit your own layout class in case you want something very specific and implement the layout yourself (for example, you may want some kind of multi-line layout, where widgets are positioned aligned horizontally, but if there's not enough space to place them all in a single line, it automatically creates a new line and continues from there. One of Qt's examples is just an implementation of this layout).

I have basically the same thing as Matthew in my GUI except I put them in the same widget. I even have the scale factors. I've build a moderately complex level editor with just that one layout widget which includes many of the standard elements in other guis (lists, menus, sliders, buttons, scrollpanes etc).

Apple has these auto resizing rules.
{"name":"Picture%202011-09-24%20at%201.57.10%20PM.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/d\/b\/db254dc1877b8491009da699f35175c7.png","w":252,"h":99,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/d\/b\/db254dc1877b8491009da699f35175c7"}

The two center lines say whether they'll stretch vertically and horizontally. The four outer lines are kind of like "stick to this wall". So the first example sticks to left and top and does no resizing. Here is a widget that would be fullscreen and resize with the window:
{"name":"Picture%202011-09-24%20at%201.58.35%20PM.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/2\/e291d8980fecf6fea037af5217f45c4a.png","w":253,"h":89,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/2\/e291d8980fecf6fea037af5217f45c4a"}

This would cling to the bottom (and left):
{"name":"Picture%202011-09-24%20at%201.59.49%20PM.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/d\/9\/d96e156019c81228799d399d6c510594.png","w":254,"h":89,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/d\/9\/d96e156019c81228799d399d6c510594"}

In addition they let you choose from some sizing logic options:
{"name":"Picture%202011-09-24%20at%202.00.52%20PM.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/a\/7a40de73629237b15472f8e9ed41a38b.png","w":259,"h":244,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/a\/7a40de73629237b15472f8e9ed41a38b"}

With those these two tools you can do most things.

I see how that works with a single widget, but how would those rules work with multiple widgets? Would that technique be combined with use of one layout cell per widget? So the cell would take up at least as much extra space as the fixed width margins as shown, and as much extra space was available for the floating margins as shown?

And as far as positioning and resizing goes with a layout manager, the positions would never be specified, but only set by the layout manager? And the sizes would be determined by a recommended size instead of having the user set the sizes explicitly?

I don't really understand this step. My widgets have virtual functions that return the absolute minimum width and height that they can occupy, but how could you ever determine what an optimum size would be? Would they follow an 'expand as space allows' rule like in Dustin's example of floating margins? Isn't that something the layout manager would have to determine, and not the widget itself?

I cannot speak for axilmar, but my algui_resize() sets the optimal size. The minimum and maximum sizes are set by another function.

Say you have a horizontal layout with three cells. The third cell contains another horizontal layout with two cells. The outer layout is 90 actual pixels wide. Its children widgets' optimal widths are represented by the numbers.

| 10 | 20 | (10, 20) |

So from that parent layout's POV, you end up with optimal widths of:

| 10 | 20 | 30 |

That's a total of 60 pixels, with 30 left over. Let's say each cell has the same stretch factor of 1. Each cell then gets an extra 10 pixels, so the cells are:

| 20 | 30 | 40 |

The layout is happy... it equals 90.

Now the child layout in the third cell looks like:

| 10 | 20 |

but since it has 40 pixels to play with, it divides the 10 extra pixels:

| 15 | 25 |

The big picture is:

| 20 | 30 | (15, 25) |

What I do then is check each widget's constraints. Maybe that first widget has a maximum width of 10. Since it has 20 pixels allocated, it then has 10 pixels of padding/margin. You can tell the cell to align left, right, or center in that case.

My approach isn't perfect because you could end up with a case where one widget is smaller than its minimum size at the same time there's another widget that is larger than its optimal size. A smarter algorithm could take some space away from the larger widget to accommodate the smaller one.

That could be done with another pass, but I didn't care enough to do anything about it because it really isn't an issue in cases that aren't contrived. All you have to do is make sure your container's minimum size is sufficient to display its children.

In practice, yes. It's the size the widget would be in the absence of a layout manager because the user explicitly requested it. (I do have a concept of "default" widget size. For instance, a button may default to being as wide as its text caption. But the programmer's request to resize the widget overrides that.)

The layout manager simply treats that size as a starting point to determine how much free space is left over. It then uses the cell's stretch factors to determine how to divide that left over space up.

Again, this is just my approach. There are many ways to do this... because generally you can trust the programmer to not create unrealistic edge cases.

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. Except in the case of widgets that have scrollable areas, and in that case I guess the 'optimum' size could be considered to be the one that shows all the contents without the aid of a scrollbar.

A button that doesn't clearly display it's text is not really a usable button. How would you know what it does? Press the button, and hope for the best? I don't strictly enforce a minimum size for my text buttons, but I probably should.

I'll agree that scrollable widgets might have a notion of an optimum size, but not all widgets could ever hope to know what their 'optimum' size is. A slider would not have any idea what it's optimum size would be, only what it's minimum size would be. Same goes for a scrollbar. What about a camera widget? What about an icon button? If it stretches it's contents, what should it's optimum size be? What about a tab? Would you want a tab that didn't fully show it's text? That's another case of a minimum size, and not an optimum size. All of these 'optimums' would have to be specified by the user.