Comparative Analysis: OpenGLUI VS GLGooey

[hailstone]

Neither of these are actively developed but the other two choices (GUIChan and CEGUI) that are, I feel are not appropriate for GAE. GUIChan doesn't have themes modifyable through files/scripts (although now I look it has an xml extension); CEGUI is too heavy weight and I don't like the casting used in the code (and a pain to integrate).

=========Features
glgooey: Dock, Layout management (flow, complexgrid, grid), signals and slots, states for components, xml skins

openglui: Java style events, everything can be setup in XML (except different states), layout management (grid, free, Y/XAXIS_LAYOUT), font manager, MediaPathManager

=========Components
glgooey: Button, CheckBox, ComboBox, TextEdit (with selection and in-game clipboard), SpinBox, ProgressBar, Slider, StaticText(label), Window (moveable), ScrollBars, MultiTextButton, ListBox, RadioButton

openglui: Button, CheckBox, ComboBox, TextEdit, Slider, StaticText(label), Window (moveable unkown), RadioButton, TabbedWindow

=========Code
glgooey: Consistent and well documented (doxygen). Appears to be good coding. Uses a renderer class but only for generic things, components are rendered in desc classes, style isn't as familiar as we're used to (ie return types on newline and separator comments), uses some bit mangling for serialisation I don't understand, uses some macros for serialisation.

openglui: very nicely formatted, some documentation, TinyXML hasn't been abstracted, organisation of code is not as good (required utils and other in a parent dir), lacks namespaces

=========Image Support
glgooey: DevIL (most you can think of) or PNG

openglui: TGA, PNG, JPEG

=========Font Support
glgooey: custom True Type Font rendering

openglui: bitmap/TGA font, font manager

=========Skin Support
glgooey: different style for different state (pressed, etc), border/background colour, font, sprite map, alpha, font size, vertical/horizontal alignment, modify the individual components, widths, strickly skin rather than define everything in xml

openglui: border/background colour, layout, texture, references other xml files, specify text, size, specify component values (eg combobox), sprite map, font

=========Integration
Both: GLUT examples, come with project files, code size is roughly the same (~2MB)

glgooey: self contained lib, good documentation in examples

openglui: can be made into a lib, might conflict since lack of namespaces

=========Conclusion
I think GLGooey is more complete and overall a better choice for Glest Advanced Engine.

It has all the features of OpenGLUI (except a tabbed window) and more. I would like to have the skinning separated into layout and appearence like how html and css are used but that can be added later.

The major difference with skinnning between the two is that OpenGLUI creates the components (and allows to input values) but GLGooey only modifies the appearence. OpenGLUI is unable to modify the different states of a component, for example, if you wanted to have different images for un/pressed button, this is not possible.

GUIChan might be worth a look but I think GLGooey is suitable.

[silnarm]

GLGooey would seem to offer more features, I just had a play with it and it looks nice and seems to run well (although example3 did hang on me once, while I was holding the the 'decrease' button of the SpinBox control).

I think the FreeType fonts is a real winner too

The XML is a bit bulky... may be worth modifying it to use attributes for colours and locations.

[Omega]

I recommend which ever one will:
1. best suit GAE's needs, both present and future
2. Be fast to impliment
3. Have less errors

I am only familiar with 2 of these, so... GLGooey?

One question: can these support animated GIFs? Can't seem to find my answer...

[hailstone]

One question: can these support animated GIFs? Can't seem to find my answer...

DevIL supports animations but I don't think GLGooey does.

[Heretik]

Neither of these are actively developed but the other two choices (GUIChan and CEGUI) that are, I feel are not appropriate for GAE.

Indeed OpenGLUI and GLGooey are not developped anymore since 2005-2006 (date of the last commits). I think this reason is strong enough _not_ to choose one of these libraries for Glest, because :
- when you'll find bugs (and you will find some), Glest coders will be the only ones who can fix it, no other coder who knows the library well already will be here to fix it.
- you'll probably hardly find anyone to discuss and help you with integration problems or any other problem with the library
- it's probably not integrated and maybe not even packaged in most Linux distribution. I only checked in Debian, but they probably aren't in other distributions either. And we would hardly find anyone who want to package an obsolete library.
- if you really go with one of these, maybe you will realise the pain it is only in some months or 1 year, and then you'll have to switch to a maintained library, loosing all the previous integration work.
- if you go with a maintained library right now, you'll do the work only once. Maybe it won't be as good as another library right now, but you can ask other people for help, bug fixing and new features, and it will improve thanks to other people while you put all your efforts on Glest itself.

GUIChan doesn't have themes modifyable through files/scripts (although now I look it has an xml extension);

So do these XML extensions allow easy theme modification finally ?

It's pity if this feature doesn't exist but I think it's not a good enough reason to throw it away without any further consideration.

CEGUI is too heavy weight

What do you mean exactly ?

and I don't like the casting used in the code

Seems more like a feeling than a real objective reason.

(and a pain to integrate).

That's the only really good argument against it, in my opinion.

I didn't make any deeper analysis of these libraries so I can't tell more about them.

I know Guichan is used in The Mana World (http://themanaworld.org/) while CeGUI is used in Secret Maryo Chronicles (http://www.secretmaryo.org/), it's probably worth asking these teams what they think of these libraries.

[wciow]

Without going into too much depth I think whichever Gui is chosen should be the one which is easiest for the end user to modify.

The whole spirit of Glest is to make it possible for those without huge coding knowledge to built their own mods/games.

[silnarm]

- when you'll find bugs (and you will find some), Glest coders will be the only ones who can fix it, no other coder who knows the library well already will be here to fix it.
- you'll probably hardly find anyone to discuss and help you with integration problems or any other problem with the library

Bugs are bugs, there's always bugs, can I assume if we decide on CEGUI that people are going rush in here to help us solve all the bugs introduced when we integrate it? I think not.

This is why the programming gods gave us debuggers, so we can figure it out for ourselves.

- it's probably not integrated and maybe not even packaged in most Linux distribution. I only checked in Debian, but they probably aren't in other distributions either. And we would hardly find anyone who want to package an obsolete library.

No package will be necessary, the chosen system will be completely integrated into the game.

- if you go with a maintained library right now, you'll do the work only once. ...  while you put all your efforts on Glest itself.

This is perhaps a very valid point.

CEGUI is too heavy weight

What do you mean exactly ?

Bigger is not always better.

[Omega]

What exactly is wrong though with crazy eddy? You are just worried about the large filesize?

Personally, I couldn't care the less as long as you guys quit arguing, and start implimenting (do first, think about bugs later ).

I personally want to see something that suits everyone's needs and has room for future improvement.

This is why the programming gods gave us debuggers, so we can figure it out for ourselves.

Jeeze, the things you nuts worship these days!

[hailstone]

To add to what silnarm has said...

This isn't a decision I'm making lightly. I've spent around 6 months playing with different GUI libs. I did manage to get CEGUI integrated with Glest, after much hassle, but I didn't like using it. The skinning/layout files and dependencies are much larger than GLGooey. The components that CEGUI has that GLGooey doesn't: tabbed window, menu bar, tooltips, multi-line edit box, popup menu and tree; These are good features but I don't see them as essential (or can't be implemented with GLGooey easliy).

Here are some questions I intend to ask the projects you provided:

How well does CEGUI fit your games' requirements?

What was the main reason you chose to use CEGUI?

Which other GUI systems had you looked at before deciding on CEGUI, if any?

Have there been any challenges with using CEGUI?

How satisfied overall are you with using CEGUI?

Do you recommend we use CEGUI for Glest?

GUI lib list - https://forum.megaglest.org/index.php?topic=3993.0

Effective C++ Third Edition by Scott Meyers [Item 27]:

Good C++ uses very few casts... Avoid casts whenever practical... When casting is necessary, try to hide it inside a function.

He uses a Window class as an example; Every component in CEGUI that you create, from an XML at least, requires a cast from a Window object. The more I read Effective C++ and the GLGooey code I see how well it has been designed.

If there are major issues with using GLGooey when I'm incorporating it I will reconsider another system but too much time has already been spent on deciding and other Glest features can't be worked on without new GUI components.