Skin loading problem

There seem to be some fundamental problems with the way skinset loading and saving is done. I have run into this issue under linux. Currently QuickGUIConfigScriptParser.cpp and I believe QuicKGUISkinSet.cpp want to write values to the directory where a skinset is loaded from. Now this is not always possible on Linux. For example, the QuickGUI default skinset, qgui on linux is generally installed into /usr/local/share/QuickGUI/media/skins or /usr/share/QuickGUI/media/skins which are generally not going to be writable from a normal user account.

There is also an issue with a "/" getting appended to the beginning of a filename, which can be a major problem especially if you're trying to load a skin from your own resource path. This causes Linux to look into the / or root directory of the filesystem and attempt to write out say the: qgui.skinset and SkinSet.qgui.png files, which is impossible from a standard user account.

I have hacked around this problem by changing the following in QuickGUISkinSet.cpp:


resourcePath = resourcePath + "/";


to:


if (resourcePath != "")
{
resourcePath = resourcePath + "/";
}


I feel there is a better solution, but I don't know my way around the code base well enough to make such changes. The current hack above causes the .skinset and .png files to be written out into the same directory the executable file is run from, which is not a good situation in my opinion.

What I would like to do is have there be a way to define where these files get written out to by the users code.

Any help or comments are greatly appreciated.

Doh! Curse Linux and its protection schemes! kidding.

The only thing I can think of is to have a QuickGUI::SettingsManager, which is a class with static methods, that will be used to specify the output directories of various files.

But now that I think about it.. the SkinSet class should load from file if it is possible, so no writing should be done. It might not be doing this in reality, but that is the intention, and we can fix it to be so. Don't know if this would be delaying the inevitable or not..

Doh! Curse Linux and its protection schemes! kidding.


It does have a tendancy to bite when you're not looking


The only thing I can think of is to have a QuickGUI::SettingsManager, which is a class with static methods, that will be used to specify the output directories of various files.

But now that I think about it.. the SkinSet class should load from file if it is possible, so no writing should be done. It might not be doing this in reality, but that is the intention, and we can fix it to be so. Don't know if this would be delaying the inevitable or not..

I guess it may depend on how many settings will be written out. I would go with whatever solution you think is best for QuickGUI's longterm future.

Right now I'm just barely hooking it into my game. It all crapped out on me with the call to: QuickGUI::SkinSetManager::getSingleton().loadSkin

Keep up the good work, right now I'll keep my hack in place so that I can continue my first adventure into using QucikGUI. I will see what other issues I uncover if any and wait for the fix.

Thanks again,

Mike

I keep forgetting how the SkinSet works with the new save/load feature. After my next commit I will familiarize and improve it if possible. Sometimes its hard balancing the "minimal assumptions, let things be as flexible as possible", and "make it as you need it" concepts when developing the library. I think for now we'll avoid the SettingsManager until it becomes painfully obvious we will need it. Users will hate me for changing things up often, but eventually will love the library as it continues to get better and better. At least.. I hope so!

I keep forgetting how the SkinSet works with the new save/load feature. After my next commit I will familiarize and improve it if possible. Sometimes its hard balancing the "minimal assumptions, let things be as flexible as possible", and "make it as you need it" concepts when developing the library. I think for now we'll avoid the SettingsManager until it becomes painfully obvious we will need it. Users will hate me for changing things up often, but eventually will love the library as it continues to get better and better. At least.. I hope so!

That's fine by me. I'm going to as I have free time this weekend attempt to use QuicKGUI without breaking things too badly, hopefully It's all in the name of progress, I keep rewriting chunks of my code when I find I don't like something, so I know how you feel.

Keep up the good work.

Mike

I have a big commit coming up soon.. hopefully sometime this weekend. Avoid use of the "setTexture" function, and if you're using your own skin, try to keep the skin textures of the same type (ie *.png, *.jpg etc.), or create multiple skins. I've fixed recent bugs brought up from zini and kali, but work on skinning leaves my current code in a non useable state lol. I think my brain is on vacation this week.