Community skin project

[Old Dog]

I don't like the batch files and environmental variables either. I have a very hard time getting some of the base skin theme packs to install correctly. I think that all of the stuff that is done in those today could be done in Appearance Manager or some other plug-in. I think it would also be good to work with sub to see if more things can be skinned on the fly without the need to shut down and restart gbpvr. It would make the experience much more interactive and user friendly.

Jeff

Appearance Manager is designed for users 5 years old and up. Our new standard should match this or better it.

[Old Dog]

BTW, I did review the skin.xml file.

My first impression is that it is OK. There are some sections that I don't recognize the need for so I will need to withhold any final conclusion.

[Fatman_do]

"A better process can be done" -- A better process that does what? What is the goal?

It is a comment on current methods more so than goals.

Now, with 'BaseSkin Designed Skins', ThemesManager, and Themepacks, changes are used by batch files being fired off. When 'BaseSkin' and 'Chameleon' are installed an application (that an associate of MixMan wrote) pops up and has the user set an environment variable %SKINROOT% to what the current ThemePack compatible skin is.

ThemePacks are a WinRAR .exe file that reads this %SKINROOT% path for "intelligent" installation of themes to the proper directory with less chance of user error.

I am not sure all goals are really defined. I am sure your intentions, mine and MixMans have somewhat a similar path, but how we walk along them and where they lead us may be different.

Here in abstract is what I feel the goals are as everone has stated so far.
Not everything stated will be practical, logical, necessary, or in harmony with everyone else.

#Make plugins more uniform in methods of skinning as much as practical to speed up skinning process for plugin authors and skinners alike.
#To help get full plugin support for skins as soon as new plugins are introduced. Skinners WILL have to address skin theme specific issues, but at least a plugin should work and look somewhat like the rest of the theme.
#Try to identify common "toolsets" (ie. common image names, textstyles, maybe menu button special elements all controlled by baseskin.xml as much as possible)
#Plugins authors should use a "fall back" method to 'blue' for plugins that do not wish to follow newer community derived guidelines.

Anyone can express specific goals in more detail, but this is what I am led to believe are wide ranging goals.

Mixman's current proposals are doing what he feels is best to address the present to get a fix that will work with current skins, while keeping an eye on the future. That may be the best solution, I don't know. It may look messy or bloated, but I know where he is comming from and what he is trying to do.

For some reason I "see" things better a day latter. I really hacked on his last proposal with blinders on. I was reading his ideas, but trying to apply what my own personal goals are, which are not in harmony with what he is trying to do all the time. I do that alot lately.

[Old Dog]

#Make plugins more uniform in methods of skinning as much as practical to speed up skinning process for plugin authors and skinners alike.

I'm not really interested in speeding up the process. I am however interested in making sure that a plug-in is skin-able at least to some defined minimum standard.

#To help get full plugin support for skins as soon as new plugins are introduced. Skinners WILL have to address skin theme specific issues, but at least a plugin should work and look somewhat like the rest of the theme.

I agree with this goal, but I don't believe it should be one of our goals.

I would be happy if we could somehow get all plug-ins updated to use the existing "unskinned plug-in fallback implementation" and to implement some kind of change detection for on-the-fly skin modifications.

#Try to identify common "toolsets" (ie. common image names, textstyles, maybe menu button special elements all controlled by baseskin.xml as much as possible)

I think we should write a baseskin.xml.

_______________

My own ideas...

I think we should develop a Community Skin. Contour was unique in that so many people participated in rewriting the skin.xml files. We should iterate through that process again to create a set of xml's that will work with an on-the-fly skin modification system. Torque should lead this effort, but he seems to be absent.

I think we should combine Appearance Manager and Theme Manager.

BTW, I'm not big on issuing directives.

[cginzel]

I've been watching this thread and the other skinning thread with interest as I'm sure many "users" are. the one thing that I see missing from Fatman_do's list is push button installation for the rest of us. I have seen many interesting skins shown in the forums and on the wiki, but for the life of me, I haven't gotten any of those fancy skins to work correctly. so I just stick with ContourHC (not meant to be a slight against ContourHC because I do like this skin) and if that stops working I would just fall back to sub's Blue. I'd like to have all of that skinning goodness you guys have worked so hard on, but honestly, if it isn't easy to install and have work, I'll pass because it doesn't add functionality.

[Fatman_do]

I've been watching this thread and the other skinning thread with interest as I'm sure many "users" are. the one thing that I see missing from Fatman_do's list is push button installation for the rest of us. I have seen many interesting skins shown in the forums and on the wiki, but for the life of me, I haven't gotten any of those fancy skins to work correctly. so I just stick with ContourHC (not meant to be a slight against ContourHC because I do like this skin) and if that stops working I would just fall back to sub's Blue. I'd like to have all of that skinning goodness you guys have worked so hard on, but honestly, if it isn't easy to install and have work, I'll pass because it doesn't add functionality.

Sassari and Chameleon have this "Push Button" installation. BaseSkin did for version 2.5, but when I tried 2.6 that was not there. It may have been added, I don't know. ThemePacks for BaseSkin and Chameleon also use a installer.

That was one of my goals, and I implemented it. I even added tips on the wiki for installer use for plugins and skins. I liked it back when TipStir first started doing that (He abondoned it after one method caused problems). I was a dumb newbie less than a year ago and that was one reason I used his skins early on.

[Fatman_do]

I'm not really interested in speeding up the process. I am however interested in making sure that a plug-in is skin-able at least to some defined minimum standard.

That goes hand-in-hand. I could have used your phrase here, I just didn't think of wording it like that. The natural result of this does lead to speeding up the process as a byproduct.

I agree with this goal, but I don't believe it should be one of our goals.

That is why my disclaimer. It is what I "pulled" in general so far. Not all the goals are clearly defined and in harmony with everyone. I left many of my own personal ones out of the list (like self-installing).

I would be happy if we could somehow get all plug-ins updated to use the existing "unskinned plug-in fallback implementation" and to implement some kind of change detection for on-the-fly skin modifications.

On-the-fly skin modifications should have been on my list, I had forgotten about this. I does relate closely to the first item about speeding up skinning in general.

I think we should write a baseskin.xml.

This comment is addressed to everyone reading.

I know that the statement is that we should "come up with an idea" that already exsists.

I would like to hear your collective thoughts on extending what should be used in baseskin.xml. One could argue how baseskin works now is fine, others could say it is underutilized. Would you like to see all "common" screen related text only referenced in baseskin.xml and only plugin specific text defined in those skins? One of the things I am trying to look into is the proper balance here, and so far I am flying solo (meaning I need more input that just the Gang of 3). I know what the answer to my questions are. Yes it would be nice if ScreenName was only defined in baseskin.xml, same for buttons.

Fine.

Seems like this is underused and if some logical structure is established, it might help out. What size fonts and where would they most likely be used is all that needs to be addressed. The color and font style is all that can be easily changed so my thoughts are, lets try to get all the lists to look like this, lets get all the descriptions to look like that. These subtle things bring harmony to a skin layout. You dont have Ariel on one screen, Tahoma on another, ect.

I know nobody really wants to say "No, define everything all over the place and keep things disjointed".

Am I wasting my time looking into it further? My textstyles list was a suggestion, not a plan of action. There needs to be responses for a plan. Heck a couple of "sounds ok to me" is enough to establish something.

I would not take the path that looks like "The Gang of 3" is going to hash everything out and the sun will rise in the morning. Otherwise it is just us three trying to ramrod something through and who the heck are we?

(stepping off of the soapbox.)

My own ideas...

I think we should develop a Community Skin. Contour was unique in that so many people participated in rewriting the skin.xml files. We should iterate through that process again to create a set of xml's that will work with an on-the-fly skin modification system. Torque should lead this effort, but he seems to be absent.

I think we should combine Appearance Manager and Theme Manager.

BTW, I'm not big on issuing directives.

There was a motion presented by McBainUK to use Chameleon, which I cannot endorse because I want to give the illusion I am humble.:p

Combining AM and ThemesManager would be a fantastic step. You could get a wishlist thread this long for feature requests.:eek:

I am also not big on issuing directives. No "thou shalt's.." comming from me.

I am a
"throw everything up against the wall and see what sticks"
"shooting from the hip"
"can we do this?"
"can I offer you a suggestion?"
"got any snacks?"

kind of guy.

[Old Dog]

That goes hand-in-hand...
..."got any snacks?" kind of guy.

Realize that if we were to create a community skin, it would not be the last skin. Others will immediately chose to ignore it.

Also, the baseskin.xml for the community skin would include what ever is necessary to support the skin and no more.

Finally, anyone can always use the community skin as a starting point for their own creativity.

[McBainUK]

I think we should combine Appearance Manager and Theme Manager.

I have no problems if AM takes over the ThemeManger'S (one) job. Be nice to have one less plugin to look after. Source is on the wiki if you need it.

[MixMan]

I suggest to keep as little text definitions as possible for plugins in the baseskin.xml

The ScreenName and Button text is enough to get a plugin looking god
The rest could be recommendations.....to use Arial or Tahoma
The same goes for the images, minimal common images.

My suggestion for baseskin text styles.
Add "WS" (Wide Screen) for 1280x720 res and add "HD" (High Definition) for 1024x768 at the end of text style. eg

<!-- Button and Title text styles 720x480 resolution -->
<TextStyle name="ScreenName" color="White" typeFace="Trebuchet MS" size="22" style="bold"/>
<TextStyle name="ScreenNameShadow" color="Grey" typeFace="Blank" size="22" style="bold"/>
<TextStyle name="ButtonText" color="White" typeFace="Arial" size="14" style="bold"/>
<TextStyle name="ButtonTextShadow" color="Grey" typeFace="Blank" size="14" style="bold"/>
<TextStyle name="ButtonTextSelected" color="White" typeFace="Arial" size="14" style="bold"/>
<TextStyle name="ButtonTextSelectedShadow" color="Grey" typeFace="Blank" size="14" style="bold"/>

<!-- Button and Title text styles 1280x720 resolution -->
<TextStyle name="ScreenNameWS" color="White" typeFace="Trebuchet MS" size="26" style="bold"/>
<TextStyle name="ScreenNameShadowWS" color="Grey" typeFace="Blank" size="26" style="bold"/>
<TextStyle name="ButtonTextWS" color="White" typeFace="Arial" size="20" style="bold"/>
<TextStyle name="ButtonTextShadowWS" color="Grey" typeFace="Blank" size="20" style="bold"/>
<TextStyle name="ButtonTextSelectedWS" color="White" typeFace="Arial" size="20" style="bold"/>
<TextStyle name="ButtonTextSelectedShadowWS" color="Grey" typeFace="Blank" size="20" style="bold"/>

<!-- Button and Title text styles 1024x768 and 1366x768 resolutions -->
<TextStyle name="ScreenNameHD" color="White" typeFace="Trebuchet MS" size="30" style="bold"/>
<TextStyle name="ScreenNameShadowHD" color="Grey" typeFace="Blank" size="30" style="bold"/>
<TextStyle name="ButtonTextHD" color="White" typeFace="Arial" size="22" style="bold"/>
<TextStyle name="ButtonTextShadowHD" color="Grey" typeFace="Blank" size="22" style="bold"/>
<TextStyle name="ButtonTextSelectedHD" color="White" typeFace="Arial" size="22" style="bold"/>
<TextStyle name="ButtonTextSelectedShadowHD" color="Grey" typeFace="Blank" size="22" style="bold"/>

Comments?