Run-Time Changes to Look&Feel

For help with general CEGUI usage:
- Questions about the usage of CEGUI and its features, if not explained in the documentation.
- Problems with the CMAKE configuration or problems occuring during the build process/compilation.
- Errors or unexpected behaviour.

Moderators: CEGUI MVP, CEGUI Team

daves
Home away from home
Home away from home
Posts: 253
Joined: Thu Feb 02, 2006 20:12

Run-Time Changes to Look&Feel

Postby daves » Tue Jul 03, 2007 13:12

Most games nowadays support a fair amount of run-time configurability of the look & feel. Things like menu backgrounds, colors, alphas, etc. Typically this would include an ability to save out the look&feel so that the next time the gamer plays the game all of the modifications are loaded by default.

Perhaps I'm viewing files such as "windows.looknfeel" and "taharez.looknfeel" incorrectly. These files seem static and it does not seem like there is an easy way to write the file back out based on dynamic tweaks to elements of the looknfeel. Certainly an alternative to saving looknfeel changes in the looknfeel file is to save changes in an application-specific configuration file that is loaded at startup.

How do ppl handle saving looknfeel changes? Is it recommended that we do this through a write to disk of the modified "application.looknfeel" or should I use a separate configuration file? If I do write the cegui looknfeel file back to disk does this mean that I have to store the entire looknfeel in code or does cegui provide a simple means to say "tweak the looknfeel by changing this parameter (e.g. frame background), and then save the updated looknfeel to disk"?

Rackle
CEGUI Team (Retired)
Posts: 534
Joined: Mon Jan 16, 2006 11:59
Location: Montréal

Postby Rackle » Tue Jul 03, 2007 17:55

Have a look at Dialog Configurations. That should provide you many of the features you desire (to be honest, any application that does not properly store/restore window's position and sizes is very annoying.

You'll have to modify the code to load/save the additional attributes that you allow your users to modify; alpha/transparency of windows, background color/image, etc.

daves
Home away from home
Home away from home
Posts: 253
Joined: Thu Feb 02, 2006 20:12

Postby daves » Tue Jul 03, 2007 20:41

Rackle wrote:to be honest, any application that does not properly store/restore window's position and sizes is very annoying.



Agreed one hundred percent and thats why im so interested in figuring out how to do this right , and how others have done it.

I'll take a look at "dialog configurations" and then get back to you with additional questions.

Thanks for taking the time.

daves
Home away from home
Home away from home
Posts: 253
Joined: Thu Feb 02, 2006 20:12

Postby daves » Tue Jul 03, 2007 21:12

Rackle wrote:Have a look at Dialog Configurations. That should provide you many of the features you desire


This does look promising.

Rackle wrote:You'll have to modify the code to load/save the additional attributes that you allow your users to modify; alpha/transparency of windows, background color/image, etc.


When the specific parameter that I want to change is the "FrameWindow" "Background color", I still am not quite sure what you would suggest. The framewindow does not have a "background color" property (though this color can be edited from within the framewindows looknfeel - for example by editing the appropriate Imagery section within the FrameWindow looknfeel def). Have you supported dynamic change of this kind of parameter? Another example is the PushButton background color (not easy to change .. though the text color on the PushButton is quite easy to change).

What would you suggest as an approach for these types of parameters?

Rackle
CEGUI Team (Retired)
Posts: 534
Joined: Mon Jan 16, 2006 11:59
Location: Montréal

Postby Rackle » Tue Jul 03, 2007 23:43

The TaharezLook scheme has a ClientAreaColour property, for example:

Code: Select all

frameWindow->setProperty("ClientAreaColour", "FFFF0000");
String clientAreaColour = frameWindow->getProperty("ClientAreaColour");


You'd have to go through the code and add this variable as a property to be managed. First you need to add a string variable to

Code: Select all

struct DialogConfig {
   CEGUI::URect position;
   bool visible;
   bool rolledup;
};

which will hold the ClientAreaColour value. Then add an Attribute name

Code: Select all

static const char clientAreaColourNameAttribute[];
and add it to the m_attributeList within DialogConfigurations(). Finally add some code within saveConfigurations(), addDialog(), applyDialogConfiguration(), elementStart(), and _setDialogAttributesMonitored().

My (old) code may not be clear enough. Nor does it seem easy enough to add new attributes to monitor. Unfortunately I do not have time for a rewrite. I'm thinking something like the following. First a virtual class to handle any parameter:

Code: Select all

class StoredParameter
{
public:
virtual void writeValue(std::ofstream& fileSave) = 0;
virtual void applyValue();
bool isMonitored() { return mMonitoredParameter; }
virtual String getAttributeTag() = 0;
private:
  bool mMonitoredParameter;


Adding a parameter then becomes as simple as:

Code: Select all

class StoredVisibleParameter : public StoredParameter
{
public:
void writeValue(const String& frameWindow, std::ofstream& fileSave)
{
  CEGUI::Window* window = CEGUI::WindowManager::getSingleton().getWindow(frameWindow);
  fileSave << window->isVisible();
};

void applyValue(const String& frameWindow, ???)
{
  CEGUI::Window* window = CEGUI::WindowManager::getSingleton().getWindow(frameWindow);
  window->setVisible(???);
}

String getAttributeTag()
{
  return "Visible";
};
private:
  bool visible;
}


This function needs some work:

Code: Select all

saveConfigurations()
{
  for each dialog configuration
  {
    for each stored parameter
    {
      if(itStoredParameter.isMonitored()
        {
        fileSave << itStoredParameter.getAttributeTag() << "=\"";
        itStoredParameter.writeValue("dialog name", fileSave);
        fileSave << "\" ";
      }
    }
  }
}


The loading part is iffy and unclear at the moment

daves
Home away from home
Home away from home
Posts: 253
Joined: Thu Feb 02, 2006 20:12

Postby daves » Wed Jul 04, 2007 14:26

Rackle,
Keep up the awesome work man. I appreciate the time you take to respond. I'll give it a crank and will post back once I have things working (may be a while because Im trying to juggle a LOT of features, and unfortunately we have a very small team).

Rackle wrote:The TaharezLook scheme has a ClientAreaColour property, for example:

Code: Select all

frameWindow->setProperty("ClientAreaColour", "FFFF0000");
String clientAreaColour = frameWindow->getProperty("ClientAreaColour");



Let me make sure I understand the flavor of this one remark. Is this to imply that the TaharezLook scheme has a ClientAreaColour and the WindowsLook scheme does not? I dont have the two schemes in front of me right now (otherwise I'd just look - and will on Monday). I wouldnt be surprised if the two schemes are different in this fashion. I thought, however, that the (programmatically settable) FrameWindow properties were the same across all schemes. If not then AWESOME, because this again points to the flexibility of the CEGUI architecture. So is it indeed true that the FrameWindow when implemented with the TaharezLook has different application settable properties than when implemented within the WindowsLook? If this is true it would be a bit confusing to me, because I have been digging in to the implementation of the various cegui widgets and have seen that the settable properties are defined within the widget C++ implementation (not within the scheme itself). Perhaps I'm missing a programmatic ability to access "attributes" defined within the scheme that do not correspond to "named properties" of the window type...

CEGUI!! :)

Rackle
CEGUI Team (Retired)
Posts: 534
Joined: Mon Jan 16, 2006 11:59
Location: Montréal

Postby Rackle » Wed Jul 04, 2007 17:08

Go through the posts about Property Finder. The Wiki links point toward a Cegui application to explore/list the properties of each widget of a scheme (FrameWindow of the TaharezLook scheme). There are also links toward the properties for the TaharezLook and the WindowsLook schemes, which were generated from that Property Finder application.

uelkfr
Not too shy to talk
Not too shy to talk
Posts: 34
Joined: Tue Dec 14, 2010 16:57

Re: Run-Time Changes to Look&Feel

Postby uelkfr » Sat Jan 01, 2011 18:29

Hi.
This was talk about saving and loading Layout features, but how about accessing LookNFeel features at runtime? For example, the WindowsLook/Titlebar have ImagerySection named "caption", which has area of TextComponent. Can somebody please show an example code to change that area?

I believe I will need to learn Falagard Window Renderer system and in this case Falagard/Titlebar renderer. Any suggestion i'm going in the right direction?
helper to newbies

"i help you, dear newbie
but nobody helps me!"

User avatar
Kulik
CEGUI Team
Posts: 1382
Joined: Mon Jul 26, 2010 18:47
Location: Czech Republic
Contact:

Re: Run-Time Changes to Look&Feel

Postby Kulik » Sat Jan 01, 2011 19:16

No experience in that area but I recall CrazyEddie saying that Falagard will have to get some bigger changes before the SkinEditor can happen. Currently it's hard to edit it at runtime.

uelkfr
Not too shy to talk
Not too shy to talk
Posts: 34
Joined: Tue Dec 14, 2010 16:57

Re: Run-Time Changes to Look&Feel

Postby uelkfr » Tue Jan 04, 2011 17:59

Yea, the meta stuff (abstraction) is always hard and a lot of work. I even believe that there should be a library with classes like Object, Properties (PropertySet), Property with XML serialization and deserialization based on SAX2, so you could just use it, not to write your own.
helper to newbies

"i help you, dear newbie
but nobody helps me!"


Return to “Help”

Who is online

Users browsing this forum: No registered users and 31 guests