Deprecate CEGUI

PolyVox · Post by **PolyVox** » Fri Sep 21, 2007 6:13 pm

KungFooMasta wrote:Sorry, I couldn't wait to read the entire thread. I cannot believe the lack of people paying attention to QuickGUI, it's depressing. In terms of its Widget set, it is behind CEGUI and RBGUI, but for ease of use, custom skinning, and notification of events, it can't be beat! And plus, I am very familiar with all the code since I wrote it, and I spend at least 3 to 5 hours a day of my own time working on the library. If you want a good GUI library, then help me create one! Sorry to rant like this, but every day I see lots of people posting on the RBGUI thread with various problems and requests, and when it comes down to it, the creators of the library are busy with their own projects. QuickGUI IS my project. For example, if I knew what widgets have the highest demand, I could focus on those. Instead, I have only a few helpful individuals who actively post on the Addon Forum. (I'm very thankful they've given me a chance)

Well let me give you some honest opinions about why this is. Firstly CEGUI is a very well known project. Dispite it's problems it has been going a long time, has (had?) a large community, and I believe that until recently it had good support. Game development is bigger than Ogre, and if you ask for a gui on gamedev.net everyone will recommend CEGUI just because it's well known. It's also the GUI used for the Ogre demos and so people (me included) will assume it's the easiest to set up and use.

As for RBGui, it simply looks very professional (just watch the videos). It may be lacking documentation, support, a linux version, a public cvs server, etc - people can see it has a lot of potential and looks professional.

Another point worth mentioning is that your gui is very new. According to the showcase forum you first showed it of in april - thats only 5 months ago. Few projects want/need to switch guis halfway through and few projects make significant progress after 5 months. Plus you are competing with betaGui; that had a few months head start and it's not immediately clear how your is different.

But in my opinion you shouldn't be competing with these. You have a separate niche - a gui which is light weight, easy to use and comes with no dependancies. So, what do you have to do to get it used? The answer is publicity.

Ask youself, how is someone supposed to find it? I've never really looked on the addon forum, I'm only aware of your project (and betaGui) the showcase forum. Keep it updated and on the front page, and take consolation from the fact that you filled 11 pages since april while begaGui did the same since november.

One of the most important things is screenshots (sad but true). Look at the first image in the QuickGui and betaGui threads. Yours shows far more widgets and features but betagui looks necer even though it just show a single button! Lay your components out, put on a nice skin, and it'll look much better. Oh, and put a link to the project in your signature. It's a free advert every time you post

I hope the above is useful, I'm sure its's a great project and, as I said in an earlier post, a ogre gui based on overlays makes a lot of sense. I'm sure it'll see more use over time...

tgraupmann · Post by **tgraupmann** » Fri Sep 21, 2007 6:14 pm

I have one gripe with my own GUI utilization, and this code be my own bug, but if FPS gets really low, the GUI suffers. I would be nice to have GUI widget take priority over other rendering so that the mouse doesn't lag in low FPS situations...

Post by **betajaen** » Fri Sep 21, 2007 6:43 pm

PolyVox wrote:I hope the above is useful, I'm sure its's a great project and, as I said in an earlier post, a ogre gui based on overlays makes a lot of sense. I'm sure it'll see more use over time...

I would like to put my thumbs up with QuickGUI as well, it's a really good system which follows most of BetaGUI's principals but has that CEGUI feel to it, and it really came together fast as well.

If it supported dynamically resizing of the widgets whilst making everything pixel perfect and no texture stretches, I'd use QuickGUI in all of the NxOgre demos and tutorials. But woe is me, it hasn't got such a feature, and I must have my lovely skins drawn out properly.

Once I've freed up my time with NxOgre which is an insane beast that demands more code everyday, I would love to move it over to the Quads system just like QuickGUI, probably in 2011.

KungFooMasta · Post by **KungFooMasta** » Fri Sep 21, 2007 6:59 pm

Thanks for the comments PolyVox, I agree I haven't actively advertised for the library.

Will work on it.

It's no longer Overlay based, I designed it from the ground up using hardware vertex buffers and rendering my own quads. From what I've seen, the batching is at a minimum, but through another QuickGUI users tests, the batching didn't seem to affect the FPS much. Maybe in more complex scenes. Either way, the new design gave me more control, and aided in making text based widgets.

@tgraupmann:

I'd also like to know the performance of QuickGUI, but I've been spending my time working on functionality and widget set.

Once I've freed up my time with NxOgre which is an insane beast that demands more code everyday, I would love to move it over to the Quads system just like QuickGUI, probably in 2011.

If it supported dynamically resizing of the widgets whilst making everything pixel perfect and no texture stretches, I'd use QuickGUI in all of the NxOgre demos and tutorials. But woe is me, it hasn't got such a feature, and I must have my lovely skins drawn out properly.

I have plans to support these in 0.9.8, but right now working on 0.9.7.

When 0.9.7 is release I recommend people looking for GUI alternatives to give it a shot. At least give me real feedback to work with.

Vectrex · Post by **Vectrex** » Sat Sep 22, 2007 7:54 am

KungFooMasta wrote:When 0.9.7 is release I recommend people looking for GUI alternatives to give it a shot. At least give me real feedback to work with.

I know this shouldn't matter but I'd put out a call to make a nice minimal skin for the demos (especially the pixel accurate version to come). It's annoying but people like RBGUI because it's default skin is really nice, not nessesarily because it's good

ps Yes the CEGUI default skin is truely awful, but at the time there were no other gui's to choose from

madmark · Post by **madmark** » Mon Sep 24, 2007 9:00 pm

Try Navi!

Firefox in Ogre.

KungFooMasta · Post by **KungFooMasta** » Mon Sep 24, 2007 9:27 pm

Firefox is for browsing web pages, right?

ajs15822 · Post by **ajs15822** » Mon Sep 24, 2007 10:13 pm

Coincidentally, I just posted about CEGUI and friends a little while ago.

And to clarify madmark, Navi is actually the layout-engine of Firefox, named Gecko, in Ogre3D.

KungFooMasta · Post by **KungFooMasta** » Mon Sep 24, 2007 10:47 pm

Interesting read. You definately have the advantage of an already well defined and used implementation of a GUI system. But what happens when you want to create something unique? How easy is it to skin? I know I've posted about ease of skinning a lot.. it seems most people want a skinset that is already provided.. but someday people will find a need to create their own interface appearance, right? Can you request notifications for things such as changes in position, size, visibility, enable/disable, dragged, etc? Can you add in notification for a specific event as its requested? Sorry for all the questions.. I haven't used navi, so I'm not aware of it's capabilities. I also don't have any knowledge of html, css and the like. (at least, not anything I can remember)

Post by **CABAListic** » Mon Sep 24, 2007 11:10 pm

Yes, this is pretty much all possible via CSS/DHTML and JavaScript.
Though, honestly I find it somewhat clumsy. All of this has evolved (websites originally being static and all that), so to me it doesn't feel designed. For all but the simplest things you'll most likely need a Javascript library.
But, if you're used to it, you can do some crazy things. It's definitely powerful, and Navi offers the full power of the Gecko rendering engine to you.

ajs15822 · Post by **ajs15822** » Mon Sep 24, 2007 11:43 pm

KungFooMasta wrote:Interesting read. You definately have the advantage of an already well defined and used implementation of a GUI system. But what happens when you want to create something unique? How easy is it to skin? I know I've posted about ease of skinning a lot.. it seems most people want a skinset that is already provided.. but someday people will find a need to create their own interface appearance, right? Can you request notifications for things such as changes in position, size, visibility, enable/disable, dragged, etc? Can you add in notification for a specific event as its requested? Sorry for all the questions.. I haven't used navi, so I'm not aware of it's capabilities. I also don't have any knowledge of html, css and the like. (at least, not anything I can remember)

In a well-crafted web page, the styles (appearance/skin), behaviors (how should the page react to events?), and actual data model (the hierarchy of elements themselves) are well-defined and separated by three different technologies:

HTML - defines the data and skeleton of the page (what are the actual elements? Who is the parent of who?)
CSS - (Cascading Style Sheets), define the appearance for elements of the page (colors, background images, dimensions, borders, fonts, etc.)
Javascript - defines the behavior of the page (what happens when I click/mouseover/drag this element?)

Thus, 'skinning' really amounts to writing a new CSS file and putting your images in the right folder. (Or using one of the hundreds of WYSIWYG Webpage Editors) (real men use notepad!)

Javascript + MooTools gives you unlimited reign over the behavior of your page, you can bind functions to almost every event possible. For example, to make an element softly fade to a yellow background (color #FFFF00) when clicked, you might write this:

Code: Select all

$('myElement').addEvent('click', function(){ this.effect('background-color').start('#FFFF00'); });

Of course, that is just the very tip of the iceberg, MooTools+JS can do much, much more than that.

(By the way, NaviLibrary includes the MooTools JS Library)

There are several basic input widgets included with HTML 4.1 (buttons, textboxes, multi-line textboxes, drop-down lists, radio buttons, etc.) all of which you can style with CSS to override their default appearance. You can easily make your own widgets using generic HTML elements (DIV, UL, LI), defining their unique appearance and behavior with CSS and Javascript, respectively.

CABAListic wrote:Yes, this is pretty much all possible via CSS/DHTML and JavaScript.
Though, honestly I find it somewhat clumsy. All of this has evolved (websites originally being static and all that), so to me it doesn't feel designed. For all but the simplest things you'll most likely need a Javascript library.
But, if you're used to it, you can do some crazy things. It's definitely powerful, and Navi offers the full power of the Gecko rendering engine to you.

Well, with the recent (last 4 years) movement into Web 2.0 (the concept of the web as an application platform), the use of web tech for other ends has become much more prolific, as is evident by things like Adobe AIR, Google Gears, and all the new Javascript UI libs.

The technologies certainly have matured to a point where they are A) well-known and popular, B) high availability of tools/help, C) standardized and stable. If you know what you're doing, there's really no creative limit to your innovation; that's why everyone calls them 'web-designers' now, the code and technology is so strong that all you need is a good designer and you're set.

Post by **CABAListic** » Tue Sep 25, 2007 12:23 am

It's not the possibilities I complain about, it's their design. I have made the mistake in the past to try to do some "simple" effects on my own, but I'll say JavaScript is just plain ugly. So even for relatively simple stuff you usually need one of the many UI libs which easily surpass a couple thousand lines of code (there are probably smaller libs, I haven't touched BLOCKED/programming for quite a while now). It's just not pretty

My concern is that HTML in itself just no longer seems to me fit for its job. It was there in the beginning when websites were really static on the user's end. And then, when that was no longer sufficient, JavaScript came as sort of a semi-external addition to make a webpage more interactive, and CSS came to make designing more flexible and powerful. So all in all you now have 3 beasts to conquer, and they are all quite different. HTML is just HTML, now-a-days could be classified as XML-like. CSS is something else, has more similarities with Ogre scripts than with HTML. And JavaScript? Again something else. It just doesn't feel completely rounded to me, and if you ask me, it could need a major redesign

But that's off-topic, sorry for that. And while I may not particularly like it, I can't argue its enormous potential. If mozlib weren't such a beast, I'd probably already be using Navi, for that matter.

ajs15822 · Post by **ajs15822** » Tue Sep 25, 2007 2:18 am

Yeah, I know exactly where you're coming from, I only recently rediscovered the whole web-scene myself.

Raw javascript lends itself to bad design decisions (un-modularized, repetitive, spaghetti-code) if you're not careful (or just ill-informed). But after really spending some time to get to know the language, I've really become fond of it: the syntax is familiar to C, prototypal-inheritance lets you do some really nifty things, and the expressivity can't be beat (I love lambdas and object literals).

Regardless, I really would've doubted the feasibility of NaviLibrary if MooTools (My Object-Oriented Tools) wasn't there for me. It's actually one of the lightest JS libs around (packed, about 44kb) and is indispensable to me as a BLOCKED-- it simply lets you write elegant, reusable code that does more with less lines. (woo, classes!)

Once you use XHTML, CSS, and MooTools+JS enough, and master all the beautifying and organization tricks, the technologies do harmonize, imo. The design patterns have taken a while to develop but you really can write beautiful code with three ugly languages.

Sure, you could hit the big reset button and call for a rewrite of the languages, but when weighed with all the additional work of porting existing technologies and the man-hours of people learning the new syntaxes, would it be worth it? Are the current languages really in such dire state?

In my opinion: no. Thus, lemons, when they're given, should be made into lemonade.

</end rant> (Sorry )

As for CEGUI, kill the bloated beast! Ogre3D's demos really could use some designer flare and the dependences on CEGUI are just a waste of space. Someone should write a simple, beautiful skin for BetaGUI or QuickGUI and be done with it.

Even I have to admit that Navi is really too heavy-weight for simple demos. If only there was an uber-lightweight, high-performance, cross-platform, stable HTML rendering engine with support for standardized CSS and JS. *sigh*

Post by **betajaen** » Tue Sep 25, 2007 10:29 am

ajs15822 wrote:As for CEGUI, kill the bloated beast! Ogre3D's demos really could use some designer flare and the dependences on CEGUI are just a waste of space. Someone should write a simple, beautiful skin for BetaGUI or QuickGUI and be done with it.

I'm hoping this fill the role with BetaGUI 2.5:

It uses one image; 128x128 PNG and one material file. If you notice none of the elements are stretched, and pixel perfect. This is down to what I call "decals" which is basically making up the buttons from three other materials; Left, Center and Right.

BetaGUI creates those buttons from the images; from a simple CSS style system (using similar syntax) to define what element looks like, font and font-size to use. It gets better since, each window can have their own separate style completely different and using different materials from the others.

Sadly BetaGUI 2.5 still uses overlays, but I'm hoping to switch over the new popular quad system when I have some spare time.

Not bad for a piece of code which is in 776 lines long.

milliams · Post by **milliams** » Tue Sep 25, 2007 12:47 pm

betajaen, that's looking really nice now. In my opinion, a small, lightweight GUI library like this is much better suited to the OGRE samples. It always seemed silly to me to have such a heavy dependency (optional, I know) just to build the samples.

Post by **betajaen** » Tue Sep 25, 2007 1:56 pm

After posting that first screen shot of BetaGUI. I came up with a thought:

"When you create a Window and it's buttons, text inputs and so on; could it be created in a way like a HTML document without worrying about coordinates, heights and widths, but still using the C++ syntax?"

With this new class I wrote, apparently it can:

Code: Select all

BetaGUI::Window* window = mGUI->createWindow(250,250,175,360, "betagui", BetaGUI::WFT_MOVE, "Node Inspector", this);
Wah w = Wah(window);
w.autoSize(true)
 .nl()
 .text("myNode").nl()
 .text("Nodes").tab().text("0")
 .nl()
 .text("Objects").tab().text("0")
 .nl()
 .text("Pose:").nl()
 .text("X").tab().input("0.0", 6, 100).tab(50).text("Roll").tab().input("0.0",6,150).nl()
 .text("Y").tab().input("0.0", 6, 100).tab(50).text("Yaw").tab().input("0.0",6,150).nl()
 .text("Z").tab().input("0.0", 6, 100).tab(50).text("Pitch").tab().input("0.0",6,150).nl()
 .button("Set Pose", (BetaGUI::ButtonMethodPtr) &Cake::setPose)
 .button("Get Pose", (BetaGUI::ButtonMethodPtr) &Cake::getPose)
 .nl()
 .text("Visibility:").nl()
 .button("Hide", (BetaGUI::ButtonMethodPtr) &Cake::hideNode)
 .button("Show", (BetaGUI::ButtonMethodPtr) &Cake::showNode)
 .nl()
 .button("Hide All", (BetaGUI::ButtonMethodPtr) &Cake::hideNodeAll)
 .button("Show All", (BetaGUI::ButtonMethodPtr) &Cake::showNodeAll)
 .nl()
 .text("Add:").nl()
 .button("Entity", (BetaGUI::ButtonMethodPtr) &Cake::showAddEntityWindow)
 .button("MObject", (BetaGUI::ButtonMethodPtr) &Cake::showAddMObjectWindow)
 .button("Node", (BetaGUI::ButtonMethodPtr) &Cake::showAddNodeWindow)
 .nl()
 .bottom()
	.left()
		.button("Select", (BetaGUI::ButtonMethodPtr) &Cake::selectNode)
    .right()
		.button("Quit", (BetaGUI::ButtonMethodPtr) &Cake::hideInspector)
;

milliams wrote:betajaen, that's looking really nice now. In my opinion, a small, lightweight GUI library like this is much better suited to the OGRE samples.

Thank you. And I agree which is why BetaGUI is always used in Cake.

Post by **Kencho** » Tue Sep 25, 2007 2:09 pm

betajaen wrote:

Code: Select all

BetaGUI::Window* window = mGUI->createWindow(250,250,175,360, "betagui", BetaGUI::WFT_MOVE, "Node Inspector", this);
Wah w = Wah(window);
w.autoSize(true)
 .nl()
 .text("myNode").nl()
 .text("Nodes").tab().text("0")
[...]
		.button("Quit", (BetaGUI::ButtonMethodPtr) &Cake::hideInspector)
;

Dude, I know this is absolutely right but... The longest sentence ever in the history of programming!

Post by **betajaen** » Tue Sep 25, 2007 2:14 pm

That was the shorter version. I was going to do a really long example about winning a competition and you had to fill in a form when completing. But some of the boost binds you see in Lua or Python are just as long.

P · Post by P » Tue Sep 25, 2007 3:44 pm

It looks pretty.

An approach I like are sizers in wxWidgets, maybe you want to look at it if you don't know them yet.

edit : to illustrate wxSizers, here is a screen of what can be done with it without any positionning :

( all knobs range from 0 to 1, totally wrong values, the logic isn't connected )

Quall · Post by **Quall** » Tue Sep 25, 2007 5:38 pm

betajaen, I too like BetaGUI. It seems to be much easier to use than CEGUI and with your recent images, skinning without stretching seems easy as well.

However, when I think of BetaGUI, I get this mentality that it is a beta GUI project loaded with bugs. I picture a library that I should stay away from and to look for an alternative that is stable. Not trying to be rude or anything, but I think it would be more popular with a different name.

KungFooMasta · Post by **KungFooMasta** » Tue Sep 25, 2007 5:52 pm

That pretty skin doesn't fool me! Just wait until I find an artist willing to make me a good skin, and QuickGUI will look just as good!

Not only that, but certain demos like the Ocean Demo require TrackBars/Sliders. Does BetaGUI have this widget?

The demo's aren't in a hurry to be changed, so we should wait some.

And also, QuickGUI works in pixel coordinates and values also, but I've been working in relative coordinates. So the ugliness is my fault. When I started working with pixel values I saw how much better everything looks.

Lacero · Post by **Lacero** » Tue Sep 25, 2007 5:55 pm

I agree with Quall, I had thought BetaGUI was just another GUI library that was in the early stages of development and the creator hadn't decided on a proper name yet.

Post by **betajaen** » Tue Sep 25, 2007 6:03 pm

@P

wxSizers do look really interesting, I can mimic some of it using tabs, and right align but not all of it. Such an implementation would require some modification of all of the widgets to allow a relative positioning to the window or another widget. Then you need an order of what they are drawn in.

@Quall/Lacero

Apart from NxOgre, everything I create using Ogre has a prefix of "Beta". Everyone knows who made it then. Jacmoe did came up with the idea of DeltaGUI but this isn't the DeltaGUI we are talking about. But then again NxOgre is still in a beta status, but it's hardly that. Half of the time it feels like version 3. Such is the same with BetaGUI.

@KungFooMasta Who I refuse to believe he knows anything about Kung Foo

Pfft, all you need is a good programmer to make a good QuickGUI.

Seriously, it will have a sliders (numerical and text based) and a status meter (progress bar, some sort of flashy colour thing,etc.)

KungFooMasta · Post by **KungFooMasta** » Tue Sep 25, 2007 6:07 pm

Pfft, all you need is a good programmer to make a good QuickGUI.

Thanks, I needed the extra motivation.

BetaGUI won't be able to compete with the next version of QGUI.

ajs15822 · Post by **ajs15822** » Tue Sep 25, 2007 6:57 pm

KungFooMasta wrote:
Pfft, all you need is a good programmer to make a good QuickGUI.

Thanks, I needed the extra motivation. BetaGUI won't be able to compete with the next version of QGUI.

I lol'd.

*Ding ding ding* The Ogre3D GUI Wars have begun!