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

[Fatman_do]

All plugins should use BaseSkin.xml
If images are used, they should be in the "Resources" folder.
BaseSkin should reference those images, in any given skin/plugin combination.
If a plugin must have it's own skin/images to work, it should also be stock Blue compatible with BaseSkin.xml, or at least have the option to use xml instead of hard coded text and/or images.

That is one of the goals is to strive to find the best way to store images and interact with those. Once a working model is started, things like this will be addressed.

This basic set of parameters would insure two things.
Every plugin would work with the Blue skin.
If a user chose a different skin, any given plugin would still work, using the Blue skin for that plugin as default, if the plugin didn't come with the users chosen main skin.

With this, we could add and remove plugins easily. Try them out, and at least get an idea of functionality.
If skin designers included a BaseSkin.xml, and plugin designers used it, then plugins could gain the skin's look, without the need to manually code a skin for each plugin.

If I'm way out in left field here, let me know. By the same token, if some (or any) of this makes sense, let's start some sort of standardization.

Sub has given us the BaseSkin.xml for a reason, yet nobody seems to use it for anything. It remains unused, as most skin designers codes skins for each portion of the "stock" gbpvr (I'm guilty of this too), and maybe only 1 or 2 plugins that they use.
Can't we get away from coding multiple skin.xml's for each bit, and simply use BaseSkin.xml?

BaseSkin and Chameleon use quite a bit in the baseskin.xml, the hard part is knowing where to draw the line. What size font should be "standard" out of the box? I am still interested in a image based blue as well as the new community skin idea as well. The image based blue should be stripped down, lean, mean, and not cater to any 3rd party plugins since sub does not support them. A set of somewhat common text styles can be established in blue that plugin developers can use, or include them in their own skin file. If the text they need does not fit a specific defined parameter, it may be best to leave it out of baseskin.xml so changes to it are harder to do. That lessens the chance of messing the plugin up.

[reboot]

Start with Blue.
Add a resources folder, put the images in it, then change BaseSkin.xml to use the images.
Can we not then remove the skin.xml from each of the standard includes?
This forces them to use BaseSkin.xml
This is the "lean, mean" image based skin, that everything else should rely on.

Add a plugin, any plugin.
It uses (as much as possible) the BaseSkin.xml, at least for menu options buttons and colours.
Specific text can be hard coded, but leave the look of the plugin to rely on BaseSkin.xml, thus colours, button sizes, location, and shapes all look the same as the main menu.

Is this feasable at all?

[Fatman_do]

Start with Blue.
Add a resources folder, put the images in it, then change BaseSkin.xml to use the images.
Can we not then remove the skin.xml from each of the standard includes?
This forces them to use BaseSkin.xml
This is the "lean, mean" image based skin, that everything else should rely on.

Add a plugin, any plugin.
It uses (as much as possible) the BaseSkin.xml, at least for menu options buttons and colours.
Specific text can be hard coded, but leave the look of the plugin to rely on BaseSkin.xml, thus colours, button sizes, location, and shapes all look the same as the main menu.

Is this feasable at all?

You know, I have never tried to put a background composite image in the baseskin.xml file to see if that works as a fall back method.

I don't know if it is necessary to add all special elements and composite images into baseskin. Maybe some generic ones, but every plugin seems to use something different.

[Fatman_do]

Here is a compostite list of all text used in the default configuration of GBPVR.

Info overload for most people.

[ATTACHMENT NOT FOUND]

[Fatman_do]

Start with Blue.
Add a resources folder, put the images in it, then change BaseSkin.xml to use the images.
Can we not then remove the skin.xml from each of the standard includes?
This forces them to use BaseSkin.xml
This is the "lean, mean" image based skin, that everything else should rely on.

Add a plugin, any plugin.
It uses (as much as possible) the BaseSkin.xml, at least for menu options buttons and colours.
Specific text can be hard coded, but leave the look of the plugin to rely on BaseSkin.xml, thus colours, button sizes, location, and shapes all look the same as the main menu.

Is this feasable at all?

Ok, I did a test, yes it worked using the background composite image in baseskin.xml instead of a plugin.

The downside. Most plugins have a screen name and images that are specific to that plugin shown on screen in the background composite image. This wont work as a skinning method for the whole skin. There really isn't a reason for it either is there? The background composite image is the easiest thing to skin for.

Now what is often different from plugin to plugin is how buttons are placed. A common button placement definition <special element> could allow for X,Y locations of buttons to be in the same relationship from plugin to plugin, if it is not specified in a specific plugin for whatever reason. The same could be true for list displays. That is something developers would have to change.

I don't know how much of what I said makes sense to the non-skinner.

[MixMan]

Start with Blue.
Add a resources folder, put the images in it, then change BaseSkin.xml to use the images.
Can we not then remove the skin.xml from each of the standard includes?
This forces them to use BaseSkin.xml
This is the "lean, mean" image based skin, that everything else should rely on.

Add a plugin, any plugin.
It uses (as much as possible) the BaseSkin.xml, at least for menu options buttons and colours.
Specific text can be hard coded, but leave the look of the plugin to rely on BaseSkin.xml, thus colours, button sizes, location, and shapes all look the same as the main menu.

Is this feasable at all?

All this have already been done in the BaseSkin skin.
The BaseSkin is a skin system that has taken almost everything in consideration. The dokumentation is not the best so I guess it is only Fatman_do that understands the BaseSkin skin.
The BaseSkin skin system is a good starting point for a discussion....to set the basic functionality for SubMenu/Plugin skins.

I am documenting the BaseSkin right now.

[McBainUK]

We all have different viewpoints. I think its time for me to bow out of the discussion as I believe its going knowhere.

The system I see is:
* A (community updated when required) Chameleon skin.
* The common images being swappable by AM - so the user can choice thier own look.
* An enhanced AM with options to swap out the common images with images being supplied as image sets:- Buttons, List items, list backgrounds, main menu backgrounds, bullet balls, popup backgrounds, popup buttons, screen saver logos, search screen backgrounds, tv guide backgrounds, task images, folder/file icons (and anything else I've missed due to writing this post quite quickly)
* MixMan's great looking themes converted to add to the range of image sets stated above.
* Good artists spending their time on creating image sets rather than editing xml or trying to work out the whole skinning system.
* A way of linking these sets into themes so a "theme" can apply multiple set changes at once.

I did consider going ahead on my own with this system but then I would add to the problem of "too many skins, plugins, options..."

McBainUK

[Old Dog]

Have to chack BlueMCE2 plugins and see what images that have been used,

Somewhere around this post http://forums.gbpvr.com/showpost.php?p=1...tcount=105
we reached a concenus that it would be best to eliminate xml lines of code by combining static graphical elements into a single file.

In addition to what was expressed earlier, I think it is worth noting that skin.xml files become more similar, many plugin backgrounds could be handled by something like this

Code:

[size=3]
<CompositeImage name="Background" size="720,480">
    <DrawImage filename="..\background.jpg" loc="0,0" size="720,480"/>        
    <DrawImage filename="StaticGraphics.png" loc="0,0" size="720,480"/> <!--Optional-->
</CompositeImage>
[/size]

If one skin variation used a list background, but the other did not, this xml code does not change!

This is what we really mean when we say image based.

Let's not get side-tracked by the multiple image file / multiple lines of xml that MCE uses. Instead we should strive to make it so the skin.xml does not(edit) change between say MCE and Mayhem.

BTW, its easy to combine static MCE plugin graphics into single files, I've done it "Piece of cake!"

[Fatman_do]

This is what I have written so far on the Baseskin sub menus,
No everthing is 100% correct yet. Have to chack BlueMCE2 plugins and see what images that have been used,
But you can see the main idea.

So why am I considered a "documentation" guy? :confused:

Will look at it further. Just glanced at it for now. Nice start.

[Old Dog]

The easiest way to develop a new look and feel for a plugin is to display it in text mode only, no graphics.

Take a screen-shot and import it into your graphics program.

Make the screen shot partially transparent and draw your new look & feel under it.

You may have many elements but you end up with a single file and if you already know what you're after, it only takes a couple of minutes.