Too many skins, too many options, too many plugins...

[Old Dog]

From my experience, with my skill set, this is not the "better" approach by declaration.

Ooops! I meant better from the end-users perspective, not really the skinners.

But tweaking elements inside a graphics program really shouldn't be any more difficult than tweaking coordinates in xml code. What makes both a pain is the need to tweak, save, stop gbpvr, start gbpvr, observe.

[MixMan]

If anyone wants to design graphic layouts with one statci image, that is OK by me. I will implement a se.png in the BaseSkin if anyone want to make an AM ThemePack that work with the BaseSkin.
There are many disadvantages with static images that you will be aware of when more XML designs will appear if we get a common image naming standard.

The new skin name should not be used by any complete skin....so the end users don't get confused.
What shall the name of the plugin "skin" be called?
Universal, Default or Standard....or do you have any other suggestion?

[Fatman_do]

Universal may be best.

Old Dog.

AM Functionality regarding SkinEffects (not what you may think).

Here is one thing that maybe can be done to simplify how it is done.

More shooting from the hip, but here it goes.

Right now, to get a "default" se.png copied to a plugin of choice (lets say SportScores), this directory has to exsist as well:
..\Appearance\SkinEffects\RoseWood\SportsScores\

And this directory doesn't contain a se.png since we want the default. If I had 20 skineffect options, that directory has to be added there as well.

Could it be possible to do this?

A: Look for se.png in a SkinEffects subfolder (It does this now)
B: If no folder is found, the default se.png file is copied to all folders in that skin. (excluding defined ones of course.)

It removes the need to create many "empty" directories and add new ones for new plugins.

Putting the gun back in the holster now.

[MixMan]

Imagine this with a Standard skin.
If plugin developers and skin designer would support this suggestion following would occur.
If we could agree upon a "minimal" image naming Standard, we could within a month have this.
All Plugins would have a Standard skin that would work with most skins/XML layouts
Have many skin designs that would work with all Advisor ThemePacks
Have many skins that would work with AM skinpacks
Possible skins/XML layouts
Sub's Blue 720x480 XML layout
Mixman's 720x480 XML layout
Fatman_do's 720x480 XML layout
Dottore's 1280x720 XML layout
Mixman's 1024x768 XML layout
MixMan's 1366x768 XML layout

[Fatman_do]

Button X direction location Suggested: Controlled by Baseskin.xml

Fatman_do’s Addendum:

Whenever possible, button SpecialElements defined in baseskin.xml for Buttons

Example:

Code:

<SpecialElement name="Buttons" loc="10,75" size="150,30" spacing="7"/>

Plugin developers are encouraged to use this scheme to control menu buttons.
If need arises to use a different scheme, then the plugin's skin will need to control this.
This would allow for consistent locations from plugin to plugin.

--End of Addendum

There may be a similar method for lists and such, but I think there is too much variation on what is needed to try to standardize on that. Buttons are probably all that is needed. I don't know what is a pain for developers.

Is constructing a special element for location and size of the info "list" without being specific a good idea? Then having "sub" special elements control the data within that general special element? I can see problems with sizes not working within a common scheme for everybody.

Plugin specific elements can still be controled by the plugin skin, just where to start with those two may go a long way. Special needs can avoid those as always.

None of these suggestions are for current plugin design, just ideas for future considerations.

[daphatty]

But tweaking elements inside a graphics program really shouldn't be any more difficult than tweaking coordinates in xml code. What makes both a pain is the need to tweak, save, stop gbpvr, start gbpvr, observe.

This brings up a good point. Maybe sub can add the ability to update the skins "on the fly?" Ironic that I was thinking about this myself after digging through the web for skin ideas that might help you guys.

[Fatman_do]

Some plugins out there, can't remember off the top of my head, actually update on the fly. I used that to skin some. Never had to exit GBPVR. I may have had to return to main menu, but not exit.

Can't remember if everything updated or not. It seems like McBainUK's might have done this.

Anyway, it seems there is a mechanism that does this.

[psycik]

Mine do this, I'm quite proud of it....

Basically I check if the skin.xml file has been updated then reload it if it has. It's pretty simple.

[Fatman_do]

Mine do this, I'm quite proud of it....

Basically I check if the skin.xml file has been updated then reload it if it has. It's pretty simple.

Yes that is it. I knew it was one of the later ones I did. (Not a knock on you I just did all the music variations last since there were so many).

It was about the time I asked you for a change to improve skinning.

[Fatman_do]

Another addendum:

Reference ListView image size is 566x489 pixel. Border is 20 pixels on all sides.
The odd values is due to that a the image was created with a 720x480 skin XML on a 800x600 resolution
and the visual look and feel set the proportions.

Concerns about 20pixel window around listviews.

I used 10 when I went through and re-did Chameleon (not knowing it was 20). Some plugins caused me fits (I did all of them) trying to fit in a 10 offset when scaling was considered and they needed to be shoe-horned in on multiple composite images and it ate up valuable space.

I am wondering if something much smaller, say 5 should be a standard. Scaling issues are minimized with a more narrow area. The majority of image based skins out there do not include any image padding like this and we need to minimize the impact on them. This cannot be seen as trying to push all of BaseSkin's methods on others.

Don't you think a five pixel zone for dropshadow effects are enough? Most of BaseSkin's 3rd party plugins are using the image from MCE2 for list backgrounds and it has no zone like this. 5 impacts this much less than 20.

Comments?