#212 Skin Development

[Anonymous]

When I set the skin to "custom" and start making new skin, something strange happens that goes away once I make a compiled skin.

When I create variation files, 2.txt, 3.txt etc, certain things won't read properly from the variation files. Example, when I set a different bitmap value inside 2.txt it doesn't always read it and make the change.

I have discovered a way to fix this during development of a skin by placing an OPTION WTF="Keep me checked for now!",1 at the bottom of the options list. Then at the bottom of all files I place [WTF] and this forces all options to be read.

Once I create a skin file I can remove all of this and it works correctly. Only when a skin is being read in custom mode do I have to do this.

It did it in 3.5 and in 3.6 so I figured I should report it. I was wondering why there is not much skin support for this awesome program. I am starting to think that anyone who ran into this trouble that was not able to figure out a work around gave up on making skins. I think if you fix this you might find out there are more people out there trying to make skins then we all realize.

Cory C.

[Anonymous]

FYI My name is Cory and have spent the last month working on a series of Skins and Start buttons. I will be releasing these skins pretty soon. I will be putting them on my site as free skins. Each one has anywhere from 5 to 18 variations with multiple options. In some cases as many as 30-40 options.

Was wondering how hard it would be if I requested some more features or capability in the source files.

Example:
OPTION LARGE_FONT="Large Fonts",0
RADIO R1 MAKE_GREEN="Green Fonts",1

Cory C.

[Ivo Beltchev]

Yes, I see a bug. You can work around it by placing
[TRUE]
as the first line of the variation text files. I automatically add it when parsing a DLL, but not when parsing a loose text file.
This will be fixed in the next version.

[Anonymous]

Ohh ok, cool thanks.

Any remark about my first comment? Radio Options?

[Anonymous]

YES, YOU ARE CORRECT

Placing [TRUE] at the top of all the variation files does fix this problem.

Just in case anyone else is having this issue, this solution is verified as a working solution and comes straight from the developer.

[Ivo Beltchev]

I am not sure exactly what you are asking, but my guess is you want an option with more than 2 states (ON/OFF). It would be a big change particularly when it comes to storing the settings in the registry.

If there is a real need for it, I may consider it for the next major version (4.0 or such). It will probably not be till next year though.

[Ivo Beltchev]

Moving this to feature requests because the original issue is now solved.

[Jcee]

seconded; I'm thinking numbers, and text input options: numbers being the easiest/stablest, and text being the most versatile.
Numeric: the skin file defines the min/max number that can be input, and possibly how many decimal places are allowed (defaults as whole numbers only)

Text: inputs text; allowing user to send arguments to the skin (how about hex codes), edit/override any variables in the skin (if the skin supports it), or ma This may cause a little bit of stability issues on the skins, but i still don't think the skins should be able to impose any formatting on the user input for text fields

to go with this added functionality, you should probably add hover-tips (text that pops up when the user hovers over an option, and can be set in the skin file), since more than a basic name may be needed to explain to the users what is needed

*overriding Any variables in a skin without skins needing to support it would be nice, if you added a field below the skin options page.. kinda a separate request though :P, and probably not user-friendly enough to be included, since you can still reshack it anyways

@ cory; id love a link if/when you get the skins your working on uploaded :P, also there is a user contents section:
https://sourceforge.net/p/classicshell/discussion/user_content/
where you could add a link, or even have it host your skins