Page 1 of 1

To theme or not to theme

Posted: 2008-07-26, 06:36
by shiv
Dear Carsten,

As you have said that you would like to put a theme sort of engine for GUIs. However, we must carefully examine the pros and cons of this. Also, suppose if we wish to provide themes how we are going to do that. One way I know is through XML files or any other text(ASCII) format which you can design and use that. There are many libraries for GUI especially and I will do a background research and tell you how they implement themes. If I remember ClanLib uses XML files.

Best regards,
Shiv :sailor:

Re: To theme or not to theme

Posted: 2008-07-26, 11:48
by Carsten
Dear Shiv,
welcome to the Ca3DE forums! :welcome:
shiv wrote:As you have said that you would like to put a theme sort of engine for GUIs. However, we must carefully examine the pros and cons of this. Also, suppose if we wish to provide themes how we are going to do that.
Indeed - I've been thinking about adding theme support to the GuiSys for a while, but it's implementation must be carefully planned.
One way I know is through XML files or any other text(ASCII) format which you can design and use that. There are many libraries for GUI especially and I will do a background research and tell you how they implement themes. If I remember ClanLib uses XML files.
Well, I'm less concerned about how the theme facility presents itself to users (except for that it should be as simple to use and work with as possible). That is, if there are ASCII files, XML or Lua config scripts, or just a subdirectory that gets a bunch of bitmaps copied into - I'm open to anything.


What I'm currently more concerned about is C++ class design. The most simple and straightforward approach that I can currently think of is introducing a new class cf::GuiSys::ThemeI, an abstract class that implements all theme functionality. The cf::GuiSys::GuiImplT instances would have a member (pointer to) an instance of a concrete class derived from theme cf::GuiSys::ThemeI.

For example, say we have classes ThemeMetalT and ThemeWoodT and ThemeColorfulT derived from ThemeI, then the GuiImplT class would be "configured" with one of these be getting it's member (a pointer to ThemeI) properly set.

The WindowT (and derived) widget classes would then access the current theme via the pointer in GuiImplT, and use it to draw themselves.

The ThemeI should have methods with which the windows can draw themselves, either on a high-level basis (e.g. DrawFrame(), DrawBorder(), DrawButton(), DrawSliderbackground(), ...), or on a lower-level basis (e.g. GetBackgndMaterialForButton(), GetFrameMaterialForListBox(), GetForegndColorForSlider(), ...).

The ThemeI derived classes would be initialized during program start by whatever means we choose, including an automatic scan of the directories which themes are available.

So far my thoughts. They are all in a very early rough draft state, and I too would like to learn more about "theming" in general, and how others do it, before making a more detailed class design.

Re: To theme or not to theme

Posted: 2008-07-26, 16:41
by shiv
Dear Carsten,

I think Lua scripts should be favored with respect to other ASCII config files so that there is less of diversity. I agree with you that C++ design is very important particularly that it should be flexible and extensible. So that in future we do not have to redo everything.

Best regards,
Shiv :cop:
These smileys are really cool. I never used to use them.