The Allegro GUI is a very flexible and easy to use user interface. But, as
we all know it doesn't look very pleasing. For your normal set of tools
this doesn't really matter. But if you want to use the GUI inside your
game, it's a different story. The GUI has to look modern and fit the theme
of the game. Most of the time, this means that we re-implement many
widgets already existing in the Allegro GUI.

On the other hand, it's very easy to change the look of the widgets. You
just need to write your own dialog_proc function, and handle only the
MSG_DRAW event, and route all other messages to the default dialog proc.

int my_button_proc(int msg, DIALOG *d, int c) {
    int ret = D_O_K;
    if (msg == MSG_DRAW) {
        /* All drawing code here */
    } else {
        ret =  d_button_proc(msg,d,c);
    }
    return ret;
}

While this is not that hard, it's still a repeating task. So, why not
write a set of dialog functions which let's us change the look of the GUI
in a very easy way? Easy as in exchanging some bitmaps and maybe adjusting
some INI file settings?
Yeah why not? So I decided to do exactly this: Writing a set of
truly skinnable dialog functions, so I can change the look of the GUI by
just replacing some image files.

{"name":"screenshot.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/4\/e4d12f04b9172211c8de6390168b6eec.jpg","w":440,"h":600,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/4\/e4d12f04b9172211c8de6390168b6eec"}
A screenshot using an Aqua style theme.

Overloaded Dialog Functions
I've prefixed all of my functions with "lex_" to avoid namespace clutter
(LEX is 3 letter entry I normally use for Hiscores). The following
functions have been overloaded:

- lex_button_proc
- lex_slider_proc
- lex_check_proc
- lex_radio_proc
- lex_edit_proc
- lex_list_proc

What's new?

I added a few extra extra features to the button and listbox.

lex_button_proc
You can specify a callback function for the button as dp2 which will be
called once you click the button. You can use this callback to check the
dialog content before it is closed. You can also make change the return
type of the button, say from D_CLOSE (close dialog) to D_O_K (do nothing)
to ensure that the dialog is not closed.
The prototype for the button callback function is:

int button_callback(int id)

The submitted id is the d1 member of the dialog struct. Set it to NULL if
you don't want to use a callback function.

I also created one new function
- lex_dialog_proc
which can be used to create a movable dialog. If you want to create a
moveable dialog box just place this function as the first dialog proc in
your DIALOG structure like this:

DIALOG the_dialog[] =
{
   /* (dialog proc)     (x)   (y)   (w)   (h)   (fg)  (bg)  (key) (flags)     (d1)                    (d2)  (dp)              (dp2) (dp3) */
   { lex_dialog_proc,   100,  100,  440,  200,    0,  -1,    0,    0,          0,                      0,    "Dialog",    NULL, NULL  },
   /* Dialog box content goes here */
}

The dp member is used for the dialog title.

The remainder works as you would expect it from the normal Allegro
functions.

To use it, simply use the lex_ prefixed dialog functions.

I've also added a slightly enhanced version of do_dialog() called (be prepared for a surprise...) lex_do_dialog() which allows you to
doubleBuffer your UI.
Check the test.c sample to see how it works.

If you want to create new skins, have a look at the provided aqua.skin file... it's heavily commented, so you should be able to create
your own skins. If you have done skins on your own, please drop me a mail.

You can download it from the (fresh, ugly but functional) lexgui homepage: [url http://www.steinke.net/allegro]

Tell me what you think... is this something you might want to use?

Spellcaster: It does look very nice indeed

Tom: That slowdown is inevitable when anti-aliasing or doing translucency

The symptoms you describe are are sure sign that there is some blending going on. No matter how fast your cpu is reading from video memory can be horribly slow.

Hm... not really. Not unless you you actually drag the dialog.
What exactly is your problem?
I have nbo problems at all speedwise. What have you tried to do, what have you changed?

Ahm... why would you want to turn the buffer into a sub bitmap? If you want to do blit to the screen, just use the normal do_dialog.
Use my function if you don't want to blit to the screen... that's the whole idea of that extended do_dialog...

i just looked at it... dragging the dialog makes the whole dialog white while dragging, and the scroll bar move while you drag it, but it goes to the place where you let go of the button. this is from running gui.exe. i have an athlon xp 1.1ghz w/geforce2. haven't looked at the code, lemme see what's going on.

Very cool;D. Will that work with the stuff posted here concerning GUI, DLG, AGUP, and a link to the GUI Clinic tutorial on the AGDN site by Daniel Harmon?
I hope so because I want to start making good GUI in games that I plan on making (Tetris(sorry I know there are a lot ot T Clones but I have to do it just once), Super Mario Bros Clone, Breakout Clone, Galga Clone, Pac Man Clone, Mrs. Pac Man Clone(don't want to be sexest;)), Tic-Tac-Toe, etc.). One question I have is would I be able to make a GUI that when you click on a menu it opens and has a pic of a character or whatever to the left of the text and menu names and that stuff? For example, if I made my World of Gaia(WoG)RPG and decided that I wanted the main character(Ryu) to be on the left side of the first menu bar to the left of the text would I be able to do that and how would I be able to do that if I can do it? My curiousity and ambition has just sky rocketed;D. Thanks in advance for any and all help you can provide;D.

Spellcaster: Oooooh pretty!
Pradeepto: I'm dumb!

I think that when they do something in a loop, they broadcast a MSG_IDLE to the whole dialog... this could be the callback you need! But it might not be easy to differentiate it from regular MDG_IDLE

I'd love to see that, lexgui as an AGUP theme. And maybe that Aqua thing (by gnudutch? sorry, I forget) too.

Cool. But please not the Clown theme from XP... shudder
OOOhhhh.. A BeOS theme would be cool too.

Just like to say, nice initiative to create a skinnable GUI, it's looking great thus far.

And a question about the scroller on the listbox in the demo program.. it doesn't follow the mouse when it is dragged. Is it supposed to do that?

Great, can't wait.

Hm... I haven't touched the menu stuff yet. But it shouldn't be too hard.

So, you want to be able to specify a BITMAP that is placed at a side of a menu?
Similar to the windows text if you open the start menu?

If this is what you want, it shouldn't be too hard to do. (I've no idea right now, because I've not used the allegro menus yet)

I'll add it to my "todo" list together with skinnable menu support.