Looks as engines

[fog]

This is my first post and I am currently using version 0.1.0 of CEGUI. Also, I am quite experienced in working with UI (text-based, GUI and web) but I never worked with "game" UI so take what I say with a grain of salt.

Three days ago I started investigating CEGUI and to test it I started to write a GUI builder for it using CEGUI only (no external widgets). Then, while working, I started to ask myself questions about CEGUI and today I tought maybe it was better to ask the forums.

This first post is about themes and how the xml files are strongly tied to the theme engine (the shared library). What I did not liked at all was having the imageset name hard-coded in the engine, limiting the configurability of new themes. Also, the need to specify the window types as engine/type makes really difficult to "try" different looks for an application.

A suggestion:

First of all don't allocate the WindowFactory object statically. When a new scheme is registered don't pass just the type but pass three arguments: the scheme name, the type without the scheme name and the imageset: something like registerFactory("Taharez", "Button", "Taharez"). Then the registerFactory instantiates a new WindowFactory passing it the imageset name (this requires modification of all the window factories) and register it as scheme/type. This makes the engines much more configurable without big changes.

Now, a very nice addition would be to have an extra parameter that tells registerFactory to register the scheme as "default", i.e., without the scheme name in the type: TaharezLook/Button -> Button. Activate that functionality with a new scheme loading method (loadDefaultScheme) and it will make easy to switch between the themes (if they provide the same set of windows). Extra, theme specific window types would always be accessible using the extended name.

What do you think about?

[CrazyEddie]

The first thing I'll say is that any of these points not satisfied by what is described below, will be non-issues when the XML driven "Falagard" widget set is ready (I have to think of the big picture, I understand that most users are more concerned with the here and now). The reason things are like they are at the moment is kind of a historical thing, and was to give a starting point for this new Mk-2 version of the system to push beyond what was available in Mk-1; the alternative was to have nothing available in a usable state - meaning that for the past 6 months there would have been nothing available, and that there would be nothing available for the next six months. Taking the approach I have has enabled many users to get started with the system. I have acknowledged many times that there are limitations in what can be customised by changing the data files alone.

Having the Imageset names coded into the 'look' modules was a general decision taken for the current two looks. Providing this as a data field in the scheme file or as a parameter somewhere else is too limiting in itself; the current system allows the use of multiple Imageset files at the discression of the person creating the look module; providing an Imageset as a parameter would basically limit you to one Imageset. As another historical note, in the Mk-1 system the 'looks' were considered purely as examples; back then it was my intention that users would write their own look modules.

The Window manager has an aliasing system. This enables multiple widget sets to be loaded, and the user can 'alias' them to some other type (you could think of this as a bit like a symlink). If you had an alias "Button", it could be mapped to any other loaded type; say a "TaharezLook/Button" or a "WindowsLook/Button" - depending on what the alias is mapped to at a given time, you will get a different object type when requesting an object from the WindowManager; the whole point of this was to enable a kind of skinning support. It is also possible to alias an existing concrete type - which effectively enables you to replace it; if you were to alias "TaharezLook/VerticalScrollbar", all the widgets that create one of these internally would then get the 'new' type instead - thus enabling customisation of compound widgets without needing to edit them directly, the same can also be achieved by registering widgets from multiple modules. I will just mention here that all the demos I have provided have been very, very basic; there is much more to the system than what has been put in the demos, which were originally written to show how things were progressing on the Mk-2 re-write in comparison to the Mk-1 system.

A "Scheme" is a high level construct which enables the library user a means to conveniently group together any number of the lower level components (Imagesets, Fonts, concrete widget types, and widget type-aliases) and have these loaded and initialised in one go. Again, what is provided in the example files is in no way intended as the only or even the recommended way of setting these files up, it was just what enabled me to do what I wanted for the demos.

I hope this has answered at least some of your points

CE.

[fog]

You answered almost all the points. Now, from the writer-of-look-modules point of view I am asking myself if you plan to extend the interface used to initialize the look modules. I can see a look module that loads its own XML definition file (the theme) but how do you tell him which one to load? Also, the look modules can require more parameters than just the name of the WindowFactory to instantiate. Have you any plan about that?

Don't take me wrong; I really like what I see of CEGUI. It is all what I miss that bothers me. Nothing is worse that having the library you're using evolve in a direction different from what you anticipated. Sometimes a roadmap (hint hint!) and asking some questions helps.

If you're not too bothered with my questions I can start another couple of threads..

[CrazyEddie]

When the XML driven look module is implemented, the interfaces and supporting frameworks will be extended and/or modified to support this.

I have a roadmap posted HERE, the dates in there are way off as I've not actually done much of anything towards any of this

Feel free to ask your questions

CE.

[fog]

Thank you very much for pointing me to the roadmap, that cleared up almost everything. I have some very generic toughts about it that I'd like to share with you.

If I understand the roadmap well it seems that CEGUI is going to be a full-fledged "generic" GUI, i.e., not explicitly targetted at games, and that IMHO is good.

I'd just like to point out that right now most of the people starting to use CEGUI in their projects are writing (or trying to write) games. So, maybe it would be better to provide some features earlier and other later. Other people probably will have their list of I-want-it-now features; mine personally is:
[list:e038899a5f]Time-based update system is good (even from an engineering point of view, a lot of other things require it.)
"Falagard", because it does not make sense to spend a lot of time customizing Taharez and then spend time again to switch to something that is clearly better.
Extended layout options.
Container widgets (see below).[/list:u:e038899a5f]
IMHO, complex widget types are not required to be there from the start and a much more important feature is to be able to embed widgets in widgets to build complex aggregates, like putting images in a list or having containers (imagine an hbox with static text and image inside a list). I know there is a way to that right now but it requires a lot of code and customization.

Keyboard accellerators are usefull but it is something a lot of games can do without.

And about the application framework, I don't understand what it would be usefull for, so I can't speak about it.

Note that I am not asking for you to change the roadmap according to my list, but just to think about the real, current target for CEGUI.

(Next post will be absolutely technical about CEGUI use. I promise.

[CrazyEddie]

Hi,

Thanks for the continued discussion

The system has been and will always be aimed at games and multimedia uses. The major reason that so many advanced widgets are being put in is because everybody seems to have a different opinion of what needs to be there, and many people say to me "Hey CE! I need widget 'x'" where widget 'x' is always different to what everybody else wants.

The roadmap has been structured in such a way that features that depend on other features appear after those dependent features in the list. The "Falagard" widget set is the 'killer' feature that most people are probably waiting for This relies on most of what comes before it in the list (with the exception of the 2nd batch of widgets), so can't be easily bumped up the order.

Your comments that refer to container widgets and the ability to embed widgets easily into other widgets has been noted. This was something I traded off when I wrote the original list widgets; there were good and bad points about having done this, and I will be re-visiting that area again.

The base work for the time based updates has been completed, although currently nothing is using it. This requires the application to inject time pulses into the system (at the top of the render loop for example).

The app framework is purely to support some samples (something other than the demos I currently have; which are now getting rather old). The idea here was/is to have a supporting framework that makes it possible to code the samples, and have them run on any OS and using any renderer available on that OS. This is what I use here for testing, I can compile a GUI app and run it under any of the renderers to ensure they all work properly. This is not something particularly essential, and in most cases will not offer much for users who already understand the system.

CE.

[fog]

Thank you very much for this discussion. I'll now move (as promised) to a technical thread.