Truly skinnable GUI for allegro released

Truly skinnable GUI for allegro released

spellcaster

Member #1,493

September 2001

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.

--
There are no stupid questions, but there are a lot of inquisitive idiots.

SystemDown

Member #663

September 2000

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

---
BEER: It's not just for breakfast anymore.

spellcaster

Member #1,493

September 2001

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.

--
There are no stupid questions, but there are a lot of inquisitive idiots.

SystemDown

Member #663

September 2000

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.

---
BEER: It's not just for breakfast anymore.

Specter Phoenix

Member #1,425

July 2001

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

Member #1,975

March 2002

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

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?

-----------------
Current projects: Allegro.pas | MinGRo

spellcaster

Member #1,493

September 2001

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.

--
There are no stupid questions, but there are a lot of inquisitive idiots.

Richard Phipps

Member #1,632

November 2001

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.

Chaos Groove Development Blog
Free Logging System Code & Blog

ReyBrujo

Moderator

January 2001

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
光子「あたしただ…奪う側に回ろうと思っただけよ」
Mitsuko's last words, Battle Royale