Run-Time Changes to Look&Feel

[daves]

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]

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]

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]

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

This does look promising.

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]

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]

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).

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]

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]

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?

[Kulik]

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]

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.