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
billyquith
Member #13,534
September 2011

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

Trent Gamblin
Member #261
April 2000
avatar

That looks good. Nice job. Not sure about std::wstring but Allegro uses utf8 so AFAIK you can use std::string.

Elias
Member #358
May 2000

Not quite sure how to convert std::wstring to ALLEGRO_USTR.

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.

Quote:

Allegro has not right alt?

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

--
"Either help out or stop whining" - Evert

weapon_S
Member #7,859
October 2006
avatar

billyquith
Member #13,534
September 2011

Elias said:

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.

Neil Walker
Member #210
April 2000
avatar

I can't see any kind of documentation or api reference?

Neil.
MAME Cabinet Blog / AXL LIBRARY (a games framework) / AXL Documentation and Tutorial

wii:0356-1384-6687-2022, kart:3308-4806-6002. XBOX:chucklepie

axilmar
Member #1,204
April 2001

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

billyquith
Member #13,534
September 2011

axilmar said:

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

That is pretty much my take on it: both docs and layout. If you have used other UI APIs then it isn't that hard to tackle. But its the annoying-ness of having to figure out which flags do what and what the difference between a margin and padding is, etc.

Perhaps reply to this issue if you would like to see docs: http://code.google.com/p/gwen/issues/detail?id=64

If you look in Gwen::Align there are some functions for doing alignment. I've added a few more myself. When I'm happier I'll add them to the GWEN issues list. I would also like to see horizontal and vertical spacers, like wx. They are very useful.

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

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.

jmasterx
Member #11,410
October 2009

@Edgar

Have you looked at Java's explanations?
http://download.oracle.com/javase/tutorial/uiswing/layout/visual.html

I find the most useful ones are FlowLayout and BorderLayout. Surprisingly, many applications happen to have 2 borders that are fixed on width, 2 fixed on height and a stretchable center area.

Oscar Giner
Member #2,207
April 2002
avatar

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

Matthew Leverton
Supreme Loser
January 1999
avatar

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.

I had my doubts as well, but after implementing just two different layouts (vertical and horizontal boxes), I was impressed at how simple it made creating dialogs.

I was going to write up something that explained it, but it's hard to do in a few words. But basically if your layout manager has cells, and each cell can contain other layout managers, you can have quite complex layouts with only two different layouts: vertical/horizontal boxes.

The two concepts I introduced to solve sizing issues were:

  • Changing algui_resize(widget, w, h) to indicate a requested size (as opposed to actual size). Added algui_set_constraints(widget, min_w, min_h, max_w, max_h).

  • Give each cell the opportunity to request a "stretch factor" which is how unused space is divvied up.

So the sizing is determined by querying each widget, asking for their requested dimensions. Then the extra space is allocated based on the stretch factors, which are just ratios.

Trent Gamblin
Member #261
April 2000
avatar

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

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

ImLeftFooted
Member #3,935
October 2003
avatar

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"}Picture%202011-09-24%20at%201.57.10%20PM.png

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"}Picture%202011-09-24%20at%201.58.35%20PM.png

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"}Picture%202011-09-24%20at%201.59.49%20PM.png

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"}Picture%202011-09-24%20at%202.00.52%20PM.png

With those these two tools you can do most things.

axilmar
Member #1,204
April 2001

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.

Layout is fairly easy to do in a GUI. It's a 2-step algorithm:

  • 1st step: let each widget take its optimum size, based on its contents. Do this first for children widgets, then for parent widgets, in order to allow parents to wrap themselves around their children.


  • 2nd step: let each widget position its contents, based on its size. Do this first for parent widgets, then for children, so as that parents define where children are positioned.

The layout algorithm has to be called in the following cases:

  • when a widget is inserted in another widget.

  • when a widget is removed from another widget.

  • when a widget is resized.

  • when a widget is hidden or shown.

  • when a visual property of a widget that affects its size is modified.

I can tell you more, if you're interested. Suffice to say that using a GUI library that has layout management is a lot better than one without.

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

Apple has these auto resizing rules.

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:

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?

Axilmar said:

1st step: let each widget take its optimum size, based on its contents. Do this first for children widgets, then for parent widgets, in order to allow parents to wrap themselves around their children.

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?

J-Gamer
Member #12,491
January 2011
avatar

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?

^This. I've been busy making a scripted layout engine, and everything on the screen needs a Position, which is user defined in percentages of the parent.

" There are plenty of wonderful ideas in The Bible, but God isn't one of them." - Derezo
"If your body was a business, thought would be like micro-management and emotions would be like macro-management. If you primarily live your life with emotions, then you are prone to error on the details. If you over-think things all the time you tend to lose scope of priorities." - Mark Oates

Matthew Leverton
Supreme Loser
January 1999
avatar

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.

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

Matthew Leverton
Supreme Loser
January 1999
avatar

Do you mean a user specified desired size?

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.

axilmar
Member #1,204
April 2001

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?

It's very easy: the optimum size is the smaller size a widget can occupy without affecting the widget's operation.

For example, in case of a button, the button's text and/or bitmap should be visible, as well as the margin.

In case of a check box, the check and the text should be visible.

In case of a text box, the minimum number of characters for the specified font should be visible.

In case of a list box, if there are few entries, then they all should be visible; if there are many entries, the first few should be visible etc.

In case of a dialog, the dialog's controls should be visible.

So, in this step, each widget lets each children specify their minimum size, then the parent specifies its minimum size. In any case, each widget specifies its size based on its contents (children widgets or text/bitmap/other).

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

axilmar said:

It's very easy: the optimum size is the smaller size a widget can occupy without affecting the widget's operation.

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.

Oscar Giner
Member #2,207
April 2002
avatar

No, the minimum size can be less. While the optimum size of a button is what aximlar said, its minimum size will be much smaller (but the text won't fit inside). axilmar definition is probably not the best, since in this case for example the button is still usable with a size smaller that its optimum (but usability is reduced since the user can't fully read the button's contents).

Optimum size is determined by the widget, not the user. The widget knows the size of the button border in a given skin/OS, and the text size.

Another example of optimum size, is the width of an line input widget with a set maximum of characters. In this case the optimum size would be the one where no matter what the user writes in it, it fits without the need for scrolling.

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

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

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.

 1   2   3 


Go to: