Truly skinnable GUI for allegro released
spellcaster

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"}screenshot.jpg
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?

Thomas Fjellstrom

Looks nice. I'll have to give that a go. Any change you'll write a dlg plugin for your addon?

Hmmm... your test doesn't update properly, it seems the objects sit in thier own loop, so Im guessing your still using some of the original gui code... and its horribly slow if i turn your Buffer into a sub bitmap of the screen and comment out the blit command...

Matt Smith

Spellcaster: It does look very nice indeed :)

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

Thomas Fjellstrom

what aliasing or translucency? I have a 900Mhtz Tbird. It shouldn't be that slow... I mean it was really slow. as if I was running windows 98 on a 486@90Mhtz, the only thing that i know that goes that slow on this machine is TuxRacer with Hardware OpenGL turned off. (with all the extra effects turned on, like shadows, trails, more aliasing, more detail, etc...)

Matt Smith

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

Thomas Fjellstrom

I dont think there is. But I haven't checked the code. I think the custom update_dialog is doing something funky casue the dialog is dragable.

spellcaster

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

Thomas Fjellstrom

I was just playing with your 'test' code. I executed it without changing a thing, and if I click a button, I don't get to see the button pressed image cause the drawing is halted till I let go of the mouse button, but by that time the button has reverted to the 'not pressed' image. The list box does the same, it doesn't draw till you stop scrolling, and when draging the dialog no objects update, but the draging is SLOOOOOWWW, slow enough to see the individual blits that update the background image.

I turned the buffer into a sub bitmap to remove the extra blit.

topaz22

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.

Pradeepto Bhattacharya

Hi all(egorites):)

Great one SC ...it really looks cool...if i may say u have CAST-A-SPELL;)...pls send me ur magic wand ...;D

Quote:

Thomas Fjellstrom : Any change you'll write a dlg plugin for your addon?

I second that thought , SC any change of that...will really help lazy bones like me;)..will luv it..

Regards
Pradeepto

Specter Phoenix

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

Ok, first of all:
All of the problems mentioned come from my lex_do_dialog(). If you use the normal do_dialog() that won't happen. On the other hand, if you use the normal do_dialog(), you don't have double buffering.

It seems like the allegro dialog functions really like to do stuff in loops, and that they don't have callback functions.
The solution is simple: I need to handle the according functions in my dialog handlers, which should be mainly cut-and-paste. Expect a new version pretty soon now :)

Quote:

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?

Let's start to work through that list step by step:
a) GUI/DLG related stuff: You can simply create a dialog using the normal gui_procs and simply put a lex_ in front of them to change them to my code.

b) Not sure what the questions are regarding AGUP and the GUI clinic tutorial?

I'm also not sure if there's interest in that kind of functionality (skinable GUI procs).

Right now I've these things on my list (most important things first):

Next release:
- Fix the double buffering code
- Make the skin loading more robust

Other things on the list
- Add a filechooser
- Additional skins
- Create a new frame work, so you can have modal dialogs.

gnudutch

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

Thomas Fjellstrom

But... I wan't DLG to show me my pretty dialogs when I make them :(

;)

Julien Cugniere
Quote:

It seems like the allegro dialog functions really like to do stuff in loops, and that they don't have callback functions.

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

Bob

Perhaps it can be merged in with AGUP, since that has Win32, GTK, and QNX Photon themes.

Peter Wang

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

spellcaster
Quote:

Perhaps it can be merged in with AGUP, since that has Win32, GTK, and QNX Photon themes.

Hm... as I said, that code can switch "themes" dynamically. So it's not really efficient to throw it together with AGUP.
In fact, I started working on that since I found the "themes" in AGUP pretty disappointing.

Hm... so you guys want more themes? Give me half an hour... ;D
It's 11:21 (locasl time here) let's see how long it will take to create a win32 theme.

Thomas Fjellstrom

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

spellcaster

Ok, it took a bit longer (had to eat dinner in between ;-) ) and also needed to change the code slightly.

{"name":"screen_bill32.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/e\/4efc335c192b01e33431796de328b98f.jpg","w":646,"h":505,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/e\/4efc335c192b01e33431796de328b98f"}screen_bill32.jpg

That's a plain and boring win98 screen.
Time needed just to create the skin from scratch: 35 minutes.

I'll upload the changed package in the evening, this should contain a better doublebuffering stratgy, also.

SystemDown

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?

spellcaster
Quote:

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?

Nope, that's a a problem with the double buffer repaint code. It will be fixed this evening.

SystemDown

Great, can't wait. :)

Specter Phoenix

Spellcaster: Thanks, but that was only the answer to my first question. What about my second question? The question was:

Quote:

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?

Here is a lame image I made in M$ Paint to illustrate what I'm asking:
http://scorpius.spaceports.com/~vgdesign/images/lame_gui_example.bmp
If that image doesn't show up I made a web page with it on there. The URL is: http://scorpius.spaceports.com/~vgdesign/lame_gui_example.html.Thanks in advance for any and all help you can offer;D.

spellcaster

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.

Specter Phoenix

Spellcaster: Yeah I started thinking about GUI and the menus and thought of adding full pictures of my characters beside the text in the menus or maybe even behind the text (still debating but I didn't know if it could be done or not). Thanks again;D.

Bob
Quote:

Hm... as I said, that code can switch "themes" dynamically.

So can AGUP. In fact, the example program does just that...

Thomas Fjellstrom

Hey, bob, can AGUP add a theme at runtime? I belive this lex_gui can.

Bob

Thomas: I don't see why not. Better ask Peter to be sure.

Thomas Fjellstrom

hmmm... I thought with AGUP you had to compile in extra functions for each theme, but with this lexgui it has themes like KDE etc...

Peter Wang

That's why I thought it would be cool to merge lexgui and AGUP, so you could have the AGUP static themes (faster), and also the lexgui "dynamic" themes (flexibler). But spellcaster doesn't want to, so that's that. There's not much point anyway, except the coolness factor. If someone wants to switch between lexgui and AGUP in one app, they can write their own wrappers.

spellcaster

Ok, new version is out:

Fixed a bug in the slider skin loading code
Added 2 new themes (bill32 and yellow)
Added better doublebuffering support
Allowed for dynamic skin switching
Added global background color attribute to the dialog skin
Added title text alignment attribute
Added title text color attribute

Works like a charm now, IMHO. All reported problems should now be fixed. The new demo allows to dynamically switch between Yellow (a beos like theme), bill32 (guess what) and the aqua theme.
Creating new skins is really fun and... so, if you want some new skins, make some suggestions :)

If you refresh your browser, you should be able to see the Themes in the screenshot above. If you're too lazy, here's the new screenshot with a new name: [url http://www.steinke.net/allegro/screenshot2.jpg]

Download the new version here:
Get it here: [url http://www.steinke.net/allegro/]

Quote:

That's why I thought it would be cool to merge lexgui and AGUP, so you could have the AGUP static themes (faster), and also the lexgui "dynamic" themes (flexibler). But spellcaster doesn't want to, so that's that

Peter: It's not that I'm against merging AGUP with my code. It's just that I don't want to do it :)
If you want to merge them, that's absolutely fine for me.

SystemDown

Great work! The new theme looks great too. I've been too lazy to do my own GUI stuff for a project I have planned, but now I think it's all taken care of :D

Thomas Fjellstrom

hmmm.. kind of odd.. I changed the mode to GFX_AUTODETECT and compiled with:

gcc *.c -o gui `allegro-config --libs`

but for some reason, the test just sits and does nothing... It works Ok in windowed mode. Ah.. Just tried with the XDGA2 driver.. Now I don't think its your problem so ignore the above ;)

but I do have another skin suggestion ;) a LCD like theme.

{"name":"skin.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/3\/03b5c6bcfc5a258cbd55ac3a8ac25c90.png","w":531,"h":398,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/3\/03b5c6bcfc5a258cbd55ac3a8ac25c90"}skin.png

spellcaster

heh, now that's a cool theme.
It will also force me to do more flexible dialog headers, which is something I've been considering anyway.
Something like this will be in the next release, promised.

If something doens't work as expected please let me know. I want the 0.95 release to be feature complete and "stable", so I can fix the remaining bugs for the 1.0 release in a couple of months.

So, keep the suggestions coming....

gnudutch

Thomas: XINE USERS UNITE!!! It's a great feeling playing proprietary Windows movies by utilizing the Windows .dll files themselves. Sweet justice!

spell: Aww you changed the pretty screenshot... :'(

Thomas Fjellstrom

ooohhh... I've been playing with DLG ;) It now works with lexgui :) muahaha.

Now I just have to figure out where to stick the 'lex_gui_shutdown' function (cause when ESC is pressed to exit the dlg 'demo' mode, it crashes). And its cool I don't have to replace the do_dialog proc, cause it may be flickering, but its much faster than double buffering when using a windowed mode...

you should make a makefile and turn the lexgui.c file into a static lib. (much easier that way for people to play with it.)

gnu: I'm dumb!. I wish I cared enough to not do such a hackish job of cropping that image... But The GIMP sucks so badly... :( hmmm...

Anyone know of a GOOD __SIMPLE__ paint program for linux?? (kpaint and xpaint arn't even as good as mspaint...)

Specter Phoenix

I'm just waiting for news on the menus ;D. Then I'll start using it:).

Richard Phipps

proportional fonts are a must for a modern gui system. Will your LEX system be able to support them spellcaster?

The basic 8x8 non-proportional font looks far too tired now!

Good work!
Rich.

Thomas Fjellstrom

I guess it all depends on taste, I find it much easier to read a fixed-width font than one that isn't.

Richard Phipps

I suppose some people will prefer the non-proportional fonts.

But if support for proportional fonts were added then the code for non-proportional fonts can be kept in and used as an option too. :D

Thomas Fjellstrom

I doubt that it doesn't support proportional fonts... With the regular allegro GUI I've used proportional fonts. Its no big deal, you just have to correctly se the size of all the items that contain text.

Richard Phipps

Hmmm..

ok! That sounds great! I'd love to see some more advanced gui screenshots (i.e. like winamp skins) using all these features..

How about it? If people make their own skins the best ones could be distributed with the library?

Rich.

spellcaster
Quote:

proportional fonts are a must for a modern gui system. Will your LEX system be able to support them spellcaster?

It will use whatever is set as "font". If you load a new, proportional font, it will use that.

I was also playing (just playing) with the idea of supporting true antialiased fonts.

Quote:

I'm just waiting for news on the menus

They will be in the next release.

Quote:

ooohhh... I've been playing with DLG It now works with lexgui muahaha.

Have you sent the changes to the author of DLG? Or could you post them here (or in a new thread maybe) so we others can use it also?

Quote:

Now I just have to figure out where to stick the 'lex_gui_shutdown' function (cause when ESC is pressed to exit the dlg 'demo' mode, it crashes).

It will be called automatically if you switch skins, bu should be called manually before you exit the program.
I'll download DLG and have a look at it.

gnudutch

GIMP is very quirky, it's hard to get used to the way it does things. But everything really is in there, you just have to find it! I've been using it for a year, and I'm only proficient at it now.

If Adobe sold Photoshop for Linux I'd buy three copies. But they don't so I have to GIMP it. :-/

Thomas Fjellstrom

hmmm.. So how do I get a line command like in ms-paint, or have a pen/pencil tool that only puts down ONE pixel?? most of the buttons on the main gimp window are useless, even the clone tool doesn't do anything if you use the current image as the source... (Im talking basic stuff, no layers.. etc..

[edit]Have you sent the changes to the author of DLG? Or could you post them here (or in a new thread maybe) so we others can use it also?[/edit]

Its a bit hackish right now cause lexgui doesn't have a makefile, and cause of the crash problem I mentioned before, but to integrate lexgui into DLG all you have to do is copy on of the other plugins and put the lexgui functions in the 'proc' list.

Peter Wang

Use the pencil or brush and plonk the first point, then hold shift and plonk the rest of the points in your line. For a single pixel pen/brush, you pick the brush size (duh ;), e.g. double clicking on circle thing on the bottom right of the main dialog, to bring up the brush selection dialog.

spellcaster: Ok, maybe some day. I've got too much on my plate already.

gnudutch

1 pixel draw: Choose pencil tool, and the smallest brush (Circle 01 1x1)

Line: Using pencil or any other tool, click the starting point, hold shift, click the ending point.

Like I say, it's in there, just gotta find it.

[edit] PETER WANG YOU ARE SCARING ME!!!

Thomas Fjellstrom

I know about the crappy line thing, I said one like ms-paint :) where it holds your hand by showing where the line would be if you dropped it. um sory, my GIMP has no circle thing at the bottom right, and neither does the one with the newest Mandrake. And I just did an upgrade on debian (unstable), so it should be up to date... But since Im using debian... They still haven't released KDE3... They say they are waiting till X4.2 is out... Oh.. wait.. It is. UGGHHSSAAAA... Sheesh it takes them forever to package stuff... considering that the newest GIMP in the debian package archives is 1.0.1...

[edit] compiling newest 'stable' gimp...

gnudutch

Thomas, be chill.

Click this to bring up the brush dialog. I currently have the 1 pixel brush selected.

http://woz.gs/tim/pix/brush.jpeg

When drawing lines with the shift key you do get a preview.

spellcaster
Quote:

How about it? If people make their own skins the best ones could be distributed with the library?

Sure, why not?
But I was thinking about putting a list of downloadable skins on my website, so the actual download doesn't get too large.

Julien Cugniere
Quote:

Now I just have to figure out where to stick the 'lex_gui_shutdown' function

Hey, couldn't you register it with atexit()? Or you can wait a week or two... I'll soon release a new version of dlg, where plugins can register init/shutdown functions, as well as menu hooks, so you can for example let the user change themes from the menus of the editor (works will with agup!).

Spellcaster: very nice! do you somehow expose the contents of the skin to the user? That way, one could make its custom procs follow lexgui's theme, whatever it would be 8-)

Thomas Fjellstrom
Quote:

Hey, couldn't you register it with atexit()

Its crashing, when exiting the DLG demo mode, you know, the one that says its dangerous? ;)

gnuduch: The problem was, the version I have doesn't have that bit, here this is what mine looks like: gimp.jpg

:) It was late last night... you can all safely ignore my late night rantings ;D

spellcaster
Quote:

do you somehow expose the contents of the skin to the user? That way, one could make its custom procs follow lexgui's theme, whatever it would be

Hm... what internals? :-)

My dialog procs are pretty simple and straight forward, since it's mainly image blitting.

But I guess I could add some of the internal helper functions to the lexgui.h file, so you can use the draw_skinned_rect() function inside your own programs.

Julien Cugniere
Quote:

Its crashing, when exiting the DLG demo mode, you know, the one that says its dangerous?

Eh! I'll see if there's a way around this...

Quote:

Hm... what internals? :-) My dialog procs are pretty simple and straight forward, since it's mainly image blitting.

Ok, never mind! I've actually looked at the code ;D, and you already export a global LexSkin. It's all good, then!

spellcaster

Ahm, 'lex_gui_shutdown' should be called only before exiting the program (or as soon as you know that you don't want to use any of the lex_ dialog procs anymore).

Had a look at DLG... now that's a nice program you wrote there :-)

Really nice work.

Niunio

I've tested the lexgui ussing the DJGPP and it works right, but I discover a small mistake in the test program: It tries to use large file names, and DOS uses the 8.3 file names, so it doesn't works right until change all file references to the 8.3 from test.c and all skin files.

And the test.exe included in the zip doesn't work in my W98, but it did in Wxp ??? I don't tried to compile with MingW32 in my computer, but I'll try tomorrow...

Somebody test it in Linux?

Thomas Fjellstrom
Quote:

Somebody test it in Linux?

Yup. Works fine for me in linux.

spellcaster

Hey, thanks for the feedback.
I'll change the extension for the skin files, so it works with dos also.
Not sure why the example program didn't run under w98, I'm using w98 myself.

Next release will contain makefiles and a vc project file. Hopes that will solve the problems.

I'm currently coding the filechooser (have a look at a first screenshot: [url http://www.steinke.net/allegro/index.html#inprogress]
The listbox dialog proc works fine already and allows you to use whatever you want as list items (not just text).
On the to-do-list are scrollbars (almost done) and a combo-box (just started) as well as menus.

For the filechooser I've implemented a small hack which allows you to access all drives as parent directory of a disc root. (So, if you go to the parent dir of C:\ youll get to the drives overview). You guys think that this is ok?

Thomas, could you test the next version in Linux before I release it? I think the filechooser should work, but since I haven't tested it yet...

And thanks again for the feedback.

gnudutch

Hmm that is very wierd Thomas. Ah well, you can also bring up the brush dialog (or any dialog) by right clicking on your image, and choosing the "dialog..." menu. Did the new version build?

SystemDown

Hey spellcaster, the in-progress file chooser looks good :)

Just wondering if I could make a request about dialogs, specifically, a dialog_proc() function to make non-movable dialogs. I'm not real sure if I could've done it easily or not by using inheritance (well, you know what I mean), but I just played around a bit with your source and made a lex_dialog_proc() which doesn't do anything with the MSG_CLICK message (I made it just broadcast a MSG_IDLE) so it can't be dragged by the title bar.

Could you possibly include something like that in the next release? Just so there's that option..
I'm thinking about writing some C++ wrappers for your functions so I can bastardize perfectly good C code to please my infatuation with objects ;D
For example I'm thinking along the lines of:

LexDialog *dialog = new LexDialog();
dialog.setMovable(true);

And so on.
But that's just an idea. I tend to do stuff like that just for the hell of it.

Anyway.. that's enough of my rant.

spellcaster
Quote:

the in-progress file chooser looks good

Thanks :-)

Quote:

Just wondering if I could make a request about dialogs, specifically, a dialog_proc() function to make non-movable dialogs. I'm not real sure if I could've done it easily or not by using inheritance

Ok, this code snippet will give an un-moveable dialog.

/** A not moving dialog */
int lex_static_dialog_proc(int msg, DIALOG *d, int c) {
    if (msg != MSG_CLICK) {
        return lex_dialog_proc(msg, d, c);
    } else {
        return D_O_K;
    }
}

Regarding the c++ wrappers: Wait a week with them. This should give me enough time to finish the filechooser, combobox and multi-line text input (And maybe the menus).

SystemDown

Ahh, yes, of course. Thanks for the hint.
I really should read up on the Allegro GUI stuff and familiarize myself more with simple inheritance like that. I tend to think in terms of inheritance with C++/Java more so.

And please, take your time with implementing those other features! I've got some brushing up to do before I get these wrappers going.. and a lot of work to do on uni projects besides.
It was just an idea anyhow, probably not something which people would want to use.
I guess I'll just see what eventuates with it.. I'll keep ya posted of course.

Thomas Fjellstrom

Awesome. spellcaster, Just awesome.

gnudutch> yeah, the new gimp built fine, just gotta install it now. :) (talk about lazy eh?)

topaz22

looks nice- have you looked at using a dirty rectangle system, tho ?

spellcaster

Next version will allow you to ask for changed rects.
While I don't think that this is needed (In game most GUIs will use a predefined space, which you can blit easily), you guys keep asking for it.

I'll add functions like:

RECT* lex_get_changed_rect();
RECT* lex_get_changed_area();

so you can use dirty rects if you want, or simply blit the changed area.

Heh, seems like the next release will contain some pretty big changes...

Wer fu

Great work spellcaster, this skin add-on is exactly what I was looking for! I will surely make a new skin (I'll post a screen shot and a link) for my game. A request: Put all this stuff in an staticly linkable library, this would be easiest of use.

A question : Is very round shaped skin would work?

Thomas - Could you post the plug-in for DLG to make it work with lexgui? I'm too lazy to write it myself ;)

SystemDown - I would be interested to work on a wrapper too. If you need help let me know! ;D

Thomas Fjellstrom

Wer fu> There is a slight problem with DLG and lex_gui. It works for the most part, but crashes when exiting from the 'Test This Dialog' option.

Wer fu

Thomas - Why not post it anyway? Maybe we'll find the bug...

Spellcaster - Why not resizable window and message box?

Niunio

I'm here again.

I've created a very interesting module. It is a utility to 'compile' the SKIN file and the BITMAPS in a DAT file and a C module wich loads this file and creates the skin. I've put it here. Read the readme.txt before do nothing.

I hope it pleases you and it will added in to the library;).

Thomas Fjellstrom

Wer Fu> Ok, I'll clean up the hack, and write some docs (*gasp*).

Richard Phipps

I think a few people are looking forward to this lexgui now! Especially if it has loads of extra features!! :)

Keep up the good work all..

Rich.

spellcaster

WerFu: Hm... I'm going to change the .skin format slightly. First of all I need to rename it to something with only 3 letters, so the dos users have less problems.

I'll also need some extra features, so you might want to wait for the next release before you start working on your theme.
I case you don't want to wait: There will be changes in the listbox skin and dialog skin, you'll need to do two scrollbar skins (horiz and vertic).
It's not that much work, but you might want to wait. I think I'll write a "How to skin lexGui" tutorial anyway.
(geez... this is becoming work 8-) )

Niunio: Downloaded the file, will have a look at it in a sec. I wanted to something like this anyway, and your contribution has saved me the time :)
Thanks a lot.

I'll start working on the gui now, I hope that I can finish the boring parts (scrollbars) today and moveon to something more interesting (multi-line input).

Niunio

spellcaster: Ok. Tell me about all changes you do and I'll update the compiler and the loader module (less work to you). And a suggestion: do not erase the 'old style' load function, it's useful while developping.

Specter Phoenix

spellcaster: If you are planning to change the .skin format slightly to a 3 character format for DOS users why not just go with .skn (it's 3 characters and it says basically the same thing:)). Also when is the next release because I'm interested to see what you can do with MENUS and DIALOGS in your skinnable GUI library:D (especially if you add the idea I was talking about).

spellcaster

Regarding the extension: i'm thinking of using either .lex (yawn) or .lsf (lex-skin-file). Or maybe just .ini
I'm also considering moving the ini file into the directory the images are stored (makes more sense IMHO).

Niunio: Heh, nice work.
I must admit though, that I don't like the idea of the "skin-compiler". I think the normal dat utility should be used to create the files.

Another point is that I think all images should be stored as BINARY. TGA or PNG compression is much better than allegro's, and if someone uses TGA or PNG (via libPNG) he should benefit from that.
So, if I move the ini file into the skin dir, you can create a single skin using: dat -a -k yellow.dat yellow/* -t FOO
Or just via the grabber.

Quote:

Also when is the next release

Ok, I've finished scrollbars and both list and listbox are now using the scrollbar widget. I will now add nicer icons to the "parent directory", "back" and "create directory" buttons inside the filechooser. Then I'll do a better combobox. This should be finished today.

Then I'll have a look at the menu code.

Then I'll do the dialog changes first, and clean up the redrawing code.

Then I'll do the menus :-)

The problem here is, that it's not just "using a skin" to do what you want. You want to use a certain image per menu.

So I think what I will have to do is to use a callback function which allows you to draw on the menus.

Is that ok for you?

Oh, planned release date for the next version is around the weekend. But there are some issues which might delay it (Episode2).
I'd also need a beta tester for the filechosser in linux... don't want to release that one untested.

SystemDown

I've got a really interesting problem with some (apparent) incompatibility between C++ and C.

I was bored for a couple of hours the other day and started a "bare bones" type C++ conversion of the lex gui procs.
All I've done so far is created a LexGuiDialog class and a LexGuiButton class for testing purposes, which basically just operates on DIALOG members and calls the right lex gui procs. Just to give an idea of how it works, here's the test program using the C++ classes (I'm only adding one button to the dialog, the "Exit" one. The dialog is using a non-movable lex_dialog_proc(), code is seen previously in this thread)

1int main (int argc, char* argv[])
2{
3 firstTimeInit();
4 
5 if (!lex_load_skin("./yellow.skin")) {
6 allegro_message("could not load skin");
7 return 1;
8 }
9 
10 // create the dialog with supplied x, y, w, h
11 LexGuiDialog* dialog = new LexGuiDialog(100, 100, 440, 200);
12 // set the first dialog in the DIALOG[] array to the static version of lex_dialog_proc()
13 dialog->setMovable(false);
14 // set the dp field
15 dialog->setTitle("Static Lex Dialog");
16 // set the internal update proc pointer to the one supplied
17 dialog->setUpdateCallback(updateScreen);
18 
19 // create the button with the supplied x, y, w, h
20 LexGuiButton* exitButton = new LexGuiButton(480, 264, 50, 24);
21 exitButton->setShortcut('x');
22 exitButton->setText("E&xit");
23 
24 // add widgets.
25 // place new widgets after the dialog proc and before the NULL proc in the internal DIALOG[] array
26 dialog->add(exitButton);
27 
28 // set background pic
29 stretch_blit(bg, dialog->getBuffer(), 0, 0, bg->w, bg->h, 0, 0, WIDTH, HEIGHT);
30 
31 // run the dialog.
32 // calls lex_do_dialog() with the internal screen update proc (which is NULL if not set)
33 bool result = dialog->run();
34 
35 // clean up. (delete and assign to NULL)
36 FREE( dialog );
37 FREE( exitButton );
38 
39 lex_gui_shutdown();
40 
41return (result ? 0 : 1);
42}
43END_OF_MAIN();

Now everything should work fine with the above, except that it crashes at "bool result = dialog->run();".
Gdb tells me that it doesn't like the line: "BITMAP *mouse_screen = _mouse_screen;" in lex_do_dialog().
Now I don't see anything at all wrong with that line.
So maybe it's the previous line, which is the function call, in which case it's probably having a beef with the supplied arguments. Now that means that it doesn't like my passing the pointer to the screen update proc which is a private member of LexGuiDialog.
So I made it public. Same problem. Then I scrapped the whole member pointer idea, and passed in a pointer to an update screen function which had no association with a class. No go.
Finally, I just passed 'NULL' as the last argument to the lex_do_dialog() call in the run() method of LexGuiDialog. Still the same runtime error.
So I've come to the conclusion that calling lex_do_dialog() from a method of a class is just doing something really bad in some way. I just can't figure out what.

The same program written in C in the proper fashion works perfectly.

Anyone got any ideas? I'll be happy to supply my complete code. Sorry for the long post.. this is just really frustrating ???

spellcaster

Just wrap all my code inside an
extern "C" clause, and compile that part using a C compiler. Next release will do this anyway, and produce a static lib.

Regarding the code: Without having a look at the Dialog class it's hard to tell what's going wrong.

SystemDown

I already had your code inside an extern "C" clause and I had it compiled in C. I guess I should've mentioned everything.. thanks for the reply though.

Anyhow, I'll just wait until the next release before doing any more, when I can statically link your routines.

Specter Phoenix
Quote:

The problem here is, that it's not just "using a skin" to do what you want. You want to use a certain image per menu.

So I think what I will have to do is to use a callback function which allows you to draw on the menus.

Is that ok for you?


That's fine with me;D.

Niunio
Quote:

I must admit though, that I don't like the idea of the "skin-compiler". I think the normal dat utility should be used to create the files.
(...)
So, if I move the ini file into the skin dir, you can create a single skin using: dat -a -k yellow.dat yellow/* -t FOO
Or just via the grabber.

But with mine you can do it using: skin2dat yellow/yellow.skn ;D

Ok, ok, don't worry.

Anyway I'll not be angry if you decide not include my skin compiler, because I learned a lot, while I writed it, about the Allegro's file functions, and I had some projects wich need them. So, no problem about it.

But you can't prohibitive(???, sorry :-[) I'll create my own compiler to use with lexgui. And if some body wants to use it, e-mail me. [url mailto:niunio@pagina.de].

Ah! To be sure about the loaddat.c will load the file in right order, I'll do some changes in that module, because the dat utility may store the data in diferent order (for example, the skin file at end, not at beginning). I have the idea about how to do it, so I'll do it this week-end, because I'll have more time and may be you'll have a new release with new things... ok?

spellcaster

Heh... don't worry. You can do anything with / for lexGUI you can think of :-)

I'm just not sure how I want the dat file skin to behave, that's all.
In fact, there are a couple of reasons why using your approach might be the best way to go. There're also some reasons why using the normal grabber / dat utility would be better.

The good thing is that a tool like this makes it very easy to "compile" a skin to a dat file. The problem is that this leads to code duplication. Your compiler uses parts of the grabber, I need to add dedicated load_from_dat() rountines, etc.

Hm... maybe I don't need to add dedicated dat file loading at all? I mean the allegro load_bitmap() function does take care of packfiles itself. So, if you store the images as binary inside the datfile, all you have to do is to use:

image=skin.dat#foo.tga

or whatever.

Right now I like this idea best. If I distribute the skins in dat files, then normal doesn't need to create the dats himself, it will save some HD space and will make it look less cluttered.

Then I could add a "How to create your own skins" document (which I need to do anyway, since I need to document the skin format better) which explains how to create the skin and how to put it into a dat once the skin is finished. This could also explain how they can embed the skins into the main datafile, etc.

Niunio, If you think that writing dedicated loading / compilation code is the better approach, please wait until the next release. The next release will be more or less feature complete (I hope), and also the skin file format shouldn't change too much afterwards.
Since you'll have to reimplement my skin loading code into your dedicated routines, so you will have less work.

(That's another reason why I think that code duplications is not the best way: Once I change something in the skin format, I would have to update several functions (my loading code, your dat loading code, and your skin compiler) just get it working again.
If I use the packfile features allegro has already, this makes my life hell of a lot more easy. And, as I coder, I'm lazy by nature, heh.

Richard Phipps

Just a quick question because I haven't used the Allegro GUI before..

Is it possible to combine dialogs with ingame action without the game being paused. I.e. if I wanted to do a starcraft game could I use Lexgui for the control panel and have the game play fine in the background.. or would the game freeze?

Thanks,
Rich.

ReyBrujo

Yes, you can by using the DIALOG_PLAYER struct and functions related. Just run the dialog for an instant, and then it leaves. You run your game a little, and then back to the dialog control. There is a small example in the allegro documents.

RB

Thread #182142. Printed from Allegro.cc