CEGUI (Crazy Eddie's GUI) Forums

Hey everyone,

First of all, I wanted to share my impressions about CEGUI:

The system is awesome, it covers all the possibilities you could ever want, sometimes at the cost of making you want to throw your computer out of the window (It happened to me once when trying to change text colors and typing "value" instead of "Value"). I think the entire project is great, and I think it would grow a lot more if it had some sort of "unified" feel to it, where an artist could just throw in their image, define the looknfeel from that image (instead of through the imageset) and move on from there. That way the beginning artists could work on the "lite" tools, and the more complex their projects become, they will actually start digging into the XML files.

Back to the topic... I have been using CEGUI for a week or so and after tweaking with a few looknfeel files I decided to make a new one for our project. I managed to succsesfully add and skin a Button and pretty much handled StaticImage, but I'm having a hard time defining StaticText components and I'm too scared to even try to build a WindowFrame widget.

Basically, I could solve a lot of my skinning issues if I could combine multiple looknfeel files into one scheme file or if I could load (and use) multiple schemes into Ogre and use them to open one layout.

Is that possible?

P.S - a little screenshot of a working title screen layout

Hi,

First, thanks for the feedback as regards to initial impressions. I think such feedback is interesting - and extremely important - as it has potential to highlight areas where perhaps improvement can be made for new users in the future.

I know what you mean about the case issue for XML attribute names. It's made worse by the fact that the newer files (like looknfeel) use all lower-case where as the layouts and other files use capitalisation. My preference nowadays is really for the all lower-case approach.

With reference to the somewhat fragmented nature of all the datafiles, this obviously has good and bad points The core reason for things being that way is because there's a lot of layering of the various concepts whereby each level builds on what went before - and adds another file to deal with that.

As far as the Imageset requirement goes, this is something on my list to be addressed; indeed it was originally intended for the 0.7.0 release, though because we did not want to delay that release too much further, certain items have been pushed back, this being one of them. So this will be eventually changed to allow the user to specify a region of a texture file directly. Something else I want to offer is the ability to load 'a bunch of images' and use those directly also (I think this is actually what you're getting at in your post?) - we kind of support this currently, by way of the automatic 'full_image' image that's defined for an Imageset created directly from an image file, though IMO it's usage needs to be more transparent in other parts of the system.

One major thing I will be focused on later this year, and moving into 2010 is in fact a skin editing tool. The changes mentioned above will be made in CEGUI to enable this tool to function in the way that I want, so there will be a nice symbiosis happening there that will benefit a lot of people in a lot of ways, I think.

With regards to skinning in general, I understand that this is a daunting - or even, as you said, scary - thing to undertake by editing the XML directly. Those three or four thousand line XML files are definitely intimidating - even for seasoned users (and CEGUI team members and project admins ). You should be glad to hear that it's possible to have multiple looknfeel files per scheme - so one XML file per 'widget' (WidgetLook) - or any other combination - is a perfectly valid approach.

If you let us know specifically what it is about the StaticText and/or FrameWindow that's giving you the heebie-jeebies we'll try and offer some help in understanding exactly what's going on in there and why

HTH, and nice screenshot

CE.

Hey Eddie,

Thanks for the quick reply.

What I meant by simplifying things is to try and make the more advanced properties always rely on some "default" definition, even when you're defining a looknfeel file. For example, if I wanted to create a new FrameWindow, I'd have to go over bit by bit in an existing looknfeel and tweak it to work with my files.

Alternatively, it would be much easier if I knew that whatever I wasn't changing would be drawn out from the default looknfeel file. So basically, every time you define a widget, you have your own new definitions from your own looknfeel file, and the default definitions that the widget need to operate but doesn't find on your own looknfeel file, would be "taken" from the default looknfeel.

I hope that made sense - just trying to make my feedback a bit more accurate.

Again, thanks for the quick reply, much appreciated!

asafy3 wrote:I think it would grow a lot more if it had some sort of "unified" feel to it, where an artist could just throw in their image, define the looknfeel from that image (instead of through the imageset) and move on from there.

I'm not sure I follow you here. What exactly does "throw in their image and define a looknfeel from that image" mean? If you do not explain it in detail we can only assume. For example, to me this reads like "I want a single tool where I can visually create an looknfeel and imageset simultaneously" though I really have no idea...

I could solve a lot of my skinning issues if I could combine multiple looknfeel files into one scheme file or if I could load (and use) multiple schemes into Ogre and use them to open one layout. Is that possible?

I don't think you can have multiple looknfeels or schemes loaded simultaneously (never tried). I did a quick search for "changing skins" and I think what you are after is partially covered here. Basically CEGUI does allow for skinning, but it is not something that is supported automagically.

What I meant by simplifying things is to try and make the more advanced properties always rely on some "default" definition, even when you're defining a looknfeel file. For example, if I wanted to create a new FrameWindow, I'd have to go over bit by bit in an existing looknfeel and tweak it to work with my files.

When you say "tweak it to work with my files" I am assuming you mean that you have to tweak the layout to accommodate for each different imageset? However I am fairly certain that the looknfeel specification supports dynamic sizing based off the dimensions of an image. So I am a bit confused here?

Alternatively, it would be much easier if I knew that whatever I wasn't changing would be drawn out from the default looknfeel file. So basically, every time you define a widget, you have your own new definitions from your own looknfeel file, and the default definitions that the widget need to operate but doesn't find on your own looknfeel file, would be "taken" from the default looknfeel.

So you want the ability to layer looknfeel specifications? How is this beneficial compared to simply copy-pasting and modifing an existing looknfeel? It sounds like you are trying to come up with an alternative method for skinning than what is already available? It sounds like too much effort for too little reward; but perhaps I'm not seeing all of the benefits?

Jamarr wrote:I don't think you can have multiple looknfeels or schemes loaded simultaneously (never tried).

Yeah, this is actually possible; so long as you avoid name collisions, you can load as many of each resource type as you want

asafy3 wrote:Alternatively, it would be much easier if I knew that whatever I wasn't changing would be drawn out from the default looknfeel file. So basically, every time you define a widget, you have your own new definitions from your own looknfeel file, and the default definitions that the widget need to operate but doesn't find on your own looknfeel file, would be "taken" from the default looknfeel.

We don't have this currently to avoid hard-coding as much as possible (I understand we're only talking about some default stuff, but still). However, one idea that has come up time and again - and it's another idea on my list of skinning enhancements - is to enable some kind of inheritance for WidgetLook definitions. Using this approach we could then provide a looknfeel containing all the basics, and users would be able to do...

or some such thing

There are a few other things I have up my sleeve for the future also, these are things that have maybe been raised a few times over the years, or things I came up with myself (yes, sometimes I still do that ). Aside from a couple of minor tweaks and additions, the Falagard skinning system remains largely unchanged from the initial implementation in 2005 - so we're due for a bit of an overhaul

CE.