Guichan is a GUI library in C++ made especially with games in mind, and it has just been released. We have done our best to create a library that is small, but powerful. The design is somewhat inspired by Java's swing, but without all the bloat (like layout handlers and such).

Main features:
- Modular object-oriented design, with replaceable back-ends for graphics and input. Allegro, OpenGL and SDL is supported out-of-the-box.
- NO themes! Instead of having a complicated theme or skin system to change the appearance of the widget - you just overload the widget's draw method and draw it any way you like.

Screenshots, downloads, documentation and additional information can be found on: http://guichan.darkbits.org/

This is the first version released to the public, so we would really like some feedback on the library, especially the API. At least, it would be very helpful if you could download it, try the examples and tell us if it worked or not.

From my little look around, the API looks neat. Should be very capable, and judging by the screenshots, it is.

edit: Error in compiling on linux. Seems it (src/widgets/icon.cpp) expects a "container.hpp" in the "include/guichan" dir, but there isn't one

I fixed the compile error in the source version. If you want to give it another try just download it again.

Edit: Ops! Found another compile error. (I had forgotten to uninstall an old version of Guichan where container.hpp was misplaced, so I didn't notice the errors when I made the test compiles). Hopefully it will now compile without errors.

Not bad...not bad at all.

Nice. I'm dloading it now to see how it compares to the snes RPG GUI lib I've been working on.

Everything seems to work fine

My question, when you make a game using this lib, does it force you to make the game play area "just another widget" ?

No it does not! Guichan never takes over your application. That is one of the main reasons we made Guichan, because most Gui's does that.
But of course, if you want to you could make your game area a widget. The main loop of a Guichan application looks something like this:

while(running)
{
  myGame->logic(); // Your Game
  gui->logic();    // Perform Gui logic such as input
  myGame->draw();  // Draw your game with Allegro or something
  gui->draw();     // Draw the Gui on top of your game graphics
  updateScreen();
}

Very impressive guys

Thank you for your comments, everyone.

Mandrake:
You should check out the source to the FF Demo on the homepage. I guess it is kind of hard to read (we hacked it together in a weekend, the code is quite messy.. and oh, it is lacking comments), so if you want to I can go through it and clean it up a bit. It also requires some knowledge to how Guichan works, so check out the other examples and the API reference first.

That’s actually what I was doing with my SNES style GUI app. It never took over your whole program.

I did actually. Read through it- very nice. Although also very different from what I was trying to accomplish.

Darn - I was thinking I'd download it and give it a spin, but the download-links don't work

Torbjörn: Ouch... Looks like our server is down. I'll let Olof kick it around a bit, and hopefully it will be up soon.

EDIT: Olof has lost internet connection where he (and the server) lives. We don't really know how long it will be down, but we'll try to find a temporary place to put the files in the meantime.

I'm sorry for our server downtime. My internet provider had a malfunction or something. But as far as I know they've fixed it for now so go and download Guichan and give us feedbacks!

The demo looks very nice - even though it uses SDL

I'm sick right now, so I don't have brains enough to check it out, but I will later - if this is as good as it seems, I'm definitely gonna have to use it

Glad you liked it, Torbjörn.

Remember that this is just a first beta version, we are still finding bugs here and there. Expect a new version not too long.

We are terribly sorry for the psychological pain this may have caused you. Anyway, the beautiful part is that demo should be quite easy to port to allegro, as it uses Guichan for drawing and input. (just take out SDL input and graphics objects, and pop in allegro's equivalents)

I just wanted to say that I looked at the docs (Doxygen-generated?) and this looks like the GUI library I've been looking for for quite awhile, if it does everything the docs seem to imply. There are a few key things missing from almost every GUI library I've seen that I've needed or wanted support for:

From what I can tell, guichan meets all of these points, so I am excited about it -- but I haven't done game development for awhile so I hesitated to comment because I would have liked to try it out first, but I wanted to make my thoughts known in the hopes that it would be an encouragement to the project.

If I do decide to use it, my game engine runs Direct3D on MSVC.NET 2003 so I would definitely work on porting the library to that environment to complete its support, but given my situation it seems unlikely.

EDIT: And my earlier mention of C++ I didn't mean C++ as in "let's put functions in a class and it's C++" but it looks like the library actually uses C++ as intended with OO design and usage of features like exceptions and std library such as std::string. Also it seems to be motivated by Java Swing and Swing's API is awesome (soft e's would call GuiChan a MVC library).

Extending Guichan to support DirectX should be fairly easy. One just have to implement a DirectX graphics class, a DirectX input class and a DirectX imageloader class. We haven't done it because none of us have enough knowledge of DirectX (and it can take some time before one of us even considers learning DirectX).
If you decide to help us we will be very happy.

Thanks!

I downloaded the FFDemo and noticed that it comes with LibPNG and only usus PNGs for the images. Is this a necessity, that is, does the library require LibPNG, or just a possible add-on? Other than that it looks wonderful. I wish I had time to Beta test it for you guys, but school is kicking my arse.

EDIT: Also, is there any plans for a DRS? You may even be able to use (with some modifying, of course) existing ones floating around here. I know Steve Terry and Miran Amon have some, but I can't tell you it's alright to use them, since it's their stuff

Everything I write is open/free source, use it as you wish... just give me the appropriate credits.

libpng is used by SDL_Image which is used by the SDL back-end to load images. So if you use the SDL back-end we supplied, then yes, you'll need libpng. The Allegro back-end does not need libpng (it uses only Allegro to load images).

DRS should be possible to implement without even changing the library itself, but you'll need to overload a few classes (widgets and graphics object). We have no plans to implement dirty rectangles in the library in the near future (we don't see any reason to).

Alright, I can probably just steal, I mean, borrow ST's then

Is it possible for people to use it if they want? Not that I want to, I'm just curious at this point

This seems like a beautifully designed GUI, and I especially like it's flexibility! Good job guys!

Sure. All images are loaded with the ImageLoader you provide at initialization. What you have to do is to create a subclass of ImageLoader (or AllegroImageLoader), that is able to load png-files with libpng into allegro BITMAPs, and use that for image loading by calling Image::setImageLoader(myAllegroPNGImageLoaderInstance).

Nope, all you need to do is to register the png format to allegro. Most allegro PNG plugins do that already, so it should work out of the box once you include the allegro pNG handler.

And I really want to check this lib out, seems to be pretty awsome

You are right, spellcaster. Somehow that seems so much easier

I spent a bit of time today looking through the code. Really great. Documented very well. I so rarely find libraries this close to my coding/design preferences. It looks like it will be really easy to do a D3D driver for this. Only one question, when is endPaint to be called? I'm thinking of batching up all of the operations in Graphics in AGP memory/vertex buffers so that I can minimize state changes (ie draw all rectangles followed by all pixels etc). If it is worthwhile I could do it there, although I just realized that it might be pointless because it seems that Guichan sets clip areas for each component when it draws, and if that is the case I doubt I could batch operations as they would all need to be drawn with the same attributes.

I suppose you mean endDraw? It is called after all the gui components has been drawn, right at the end of Gui::draw (that is, once per frame). So I guess the clip areas might give you some trouble... Perhaps you can do the drawing in popClipArea, or compute how the primitives will look after clipping and draw that in endDraw?

Anyway. If you do create a Direct3D graphics class we would really much want to get our hands on it, to add it to the library.

We have released an update of Guichan and a new demo showing Guichan on top of OpenGL.

They can both be found here: [url http://guichan.darkbits.org/downloads.shtml]
And here is the ChangeLog: [url http://guichan.darkbits.org/ChangeLog]
Demo screenshots!: [url http://guichan.darkbits.org/screenshots.shtml]