CEGUI (Crazy Eddie's GUI) Forums

I'd like to solicit opinions on creating a simplified interface for CEGUI. CEGUI can do an awful lot, but it's also kind of a lot to swallow when all you want is a quick list of option buttons in the middle of the screen.

So what could be done to create a sort of CE-EZ interface to the existing API?

When I want to throw together a UI for my GL program quickly, I typically use GLUI (http://glui.sourceforge.net/). With GLUI you can come pretty close to the ideal of 1 line of code per widget displayed. It's great. But it also requires GLUT (ick!) and it's pretty inflexible. Great for a rapid prototype, but when you need start adding more functionality it's just not possible. (Want an image on a button -- TOO BAD!)

In my thinking, some sort of GLUI-like wrapper for CEGUI would be great. I once did a little experiment to see if I could emulate GLUT using FOX. The little one-day experiment went pretty well, I think (http://www.billbaxter.com/projects/fox/fxglut/). I got to where I could make windows and set up call-backs using something very close to the glut API. After that my plan was to emulate GLUI as well, but I didn't get that far. I still think it's possible. Espeically since the goal was not 100% compatibility but something that had the same degree of ease-of use, without the severe restrictions.

What other approaches are possible for making CEGUI easier to use for slapping together quick prototypes? A fellow in another thread suggested that better GUI editors are the way to go. If you have that, then ease of use is solved, he seemed to be saying.

Thoughts?

There's already an editor existing and doing the layout stuff pretty well. It has some limitation but it's working


We are also thinking at some "lua" interface to do in lua everythings done through XML maybe with a simplified api

Dalfy wrote:There's already an editor existing and doing the layout stuff pretty well. It has some limitation but it's working


We are also thinking at some "lua" interface to do in lua everythings done through XML maybe with a simplified api

For me anyway, when I'm slapping together a prototype, usually I don't care about the layout that much. I want a slider to let me frob my doohicky on the screen. I just want it to be visible somewhere. In those cases its a huge interruption of flow to have to go over to another GUI editor program tweak the UI and save.
That's what makes GLUI so nice for quickie GUIs. It has a simple built-in layout algorithm that just starts putting things on the screen one after another, generally in columns. It's much nicer for quickie GUIs to just be able to say something like:

and be done. No messing with external GUI editors and externally loaded files etc. If I want the button to only be there in debug mode I just slap on an #ifdef _DEBUG, and it's golden.

I'm not saying there's no merit to having layouts generated by GUI editors and loaded from resource files. Just that going that route is overkill for things that should be really simple.

I looking to put a little more of the philosophy of "simple things are simple and difficult things are doable" into CEGUI. Right now I think it's more like "simple things and difficult things are doable".

You also mention scripting, but to me that's just another layer of hassle that's not really needed for a quick one-off prototype.

List widgets and tabbed notebooks and treeview controls are nice, but probably 90% of game GUIs consist of buttons, menus (made out of buttons), sliders, and maybe one-line text entry. Those things should be laughably easy for the programmer to slap together.

If you haven't caught the drift, basically what I want is a replacement for GLUI that doesn't have GLUI's glass ceiling.

BTW -- if you didn't notice I'm one of the current "maintainers" of GLUI. "maintainers" in quotes because there's not a whole lot of maintenance going on. I personally don't feel motivated to put any more time into it, because short of rewriting large chunks of it to remove the GLUT dependency, there's really no way to solve most of its deficiencies. I'd much rather work the other way to bring CEGUI down to the level of ease-of use of GLUI so that there's truly no reason to use GLUI any more.

My current thinking is that some sort of wrapper/interface API would be the way to go for this. Basically it would make a lot of decisions for you by default, like GLUI, in terms of layout etc, but unlike GLUI the hope is that it will be possible to gradually refactor your code into something that uses more and more features of CEGUI as your requirements become more specific.

Have you seen the UI used in DirectX demos? I'd like to see something like that become super easy to create using CEGUI.

I agree that CEGUI is'nt exactly the easiest library to get started with, but once you get the basics right it's not rocket science.

The most useful case for something like this would some kind of "library" that contains all the support code people on different platforms need to get going with CEGUI.
It could be as simple as providing some source files people can just include in their projects.

This "library" would have the methods needed to properly inject input and timepulse. Have some CEGUIInit() function that initialises CEGUI using the appropriate renderer etc.
Having a "library" like this would mean that users could use an extremely small API to integrate CEGUI into their application and the just start using it right away.

A little CEGLUI project would be very nice!

The more I think about this, the more I like it. It would be handy to have, both for me and others. It would give me a good excuse to figure out the internals of CE fairly well. And it would give me a good alternative to point GLUI users to.

@Lindquist: you may be right, the best way to go may be just to make some templates per-config. But I'd prefer something more like a traditional library. I'll have to give it some study to see what's possible.

Either way, it would be nice to have some demos that could be used as a starting point for writing an app. The demo framework is nice in terms of saving on redundant code in the demos, but it's not such a great place to start a new app. But since it's there, that's what a lot of people end up starting off with.

Maybe another way to go would just be a special kind of custom widget or two with built-in layout logic and a simplified API for adding child widgets in a GLUI-like way. So you still have to go through the standard one-time CEGUI setup rigamarole, but afterwards you can get more or less GLUI's one-line-of-code-per-widget efficiency.

The setup stuff could be a separate little library for that matter.

Yeppers, I think I'm going to give this a go. If nothing else, I'll come out with a better understanding of CEGUI, so there's not much to lose.