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

[Fatman_do]

Don't worry anyone.

Sassari is ready for full testing. Nobody will care soon...

Dottore, are you a graphic artist by trade?

Have to study it for a while. Be back later.

[MixMan]

AM already has parts of the functionality....with swapping our all common images. But AM uses sub directories for the overlays.....so there is a "complex" directory structure for a "theme"
A new AM that could change themes with a simple directory structure would be nice. Fonts and sounds should also be taken into consideration for a design.

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]

AM already has parts of the functionality....with swapping our all common images. But AM uses sub directories for the overlays.....so there is a "complex" directory structure for a "theme"
A new AM that could change themes with a simple directory structure would be nice.

Amen.

[Old Dog]

Fonts and sounds should also be taken into consideration for a design.

I've never used sounds and AM doesn't currently support them so I'll take an otimistic perspective and assume they'll be easy.

Font swapping is something that I think we will need to strain our brains over. I think you have spent more time trying to implement a solution than I have, and I bet its been a bear.

As mentioned by others, I suspect this is something we don't want to leave completly in the hands of the end user. Instead we might wish to create a mechanism that allows the skinner to associate and swap sets of fonts for use with different sets of graphical elements.

(sounds like a grizzly)

[Fatman_do]

Amen.

Maybe some sort of theme definition file? Something that tells AM what images to pull from what directories for a theme. Then a user can tweak any theme to their liking. Mixman has some themes that are very similar (2 contour and several MCE2 styles). The only difference is some minor image changes. This would reduce theme design to focus more on compostion than possible image combination varaitions. Themes and AM could share a common image pool directory similar to the Appearance directory now, where seperate elements are stored.

It looks like combining both tool sets into one would give the most flexibility.
A theme that wanted a single image overlay could call up that image and copy over blank counterparts of a multi-image theme. The same could be in reverse, or a combination of both.

Does that sound crazy?

[Old Dog]

Does that sound crazy?

Only partially, but then you are shooting from hip!

Maybe some sort of theme definition file? Something that tells AM what images to pull from what directories for a theme. Then a user can tweak any theme to their liking.

This sounds too much like what we're trying to get away from. Just call the definition file "theme.xml", see what I mean?

The rest isn't so crazy, but you do keep thinking I'm going to budge on the single static graphics file. I'm not.

BTW, you guys are just being stuburn, not me.

[Fatman_do]

Only partially, but then you are shooting from hip!

This sounds too much like what we're trying to get away from. Just call the definition file "theme.xml", see what I mean?

The rest isn't so crazy, but you do keep thinking I'm going to budge on the single static graphics file. I'm not.

BTW, you guys are just being stuburn, not me.

You don't have to budge. Can't both ideas co-exsist? A plugin author can do what they feel most comfortable with.

[Old Dog]

MixMan,

The comment in my previous post is not directed at you because on a few different occasions during the past few months you have acknowledged that the single static skin file has some technical merit. I appreciate that very much.

Best Regards,
David

[Old Dog]

A plugin author can do what they feel most comfortable with.

This issue doesn't affect the plugin author. It defines the process that skinners must follow, a process that maximizes the benefit for the end-user.

[MixMan]

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!"

I am positive to define a static graphics image located in the plugin skins directory, like the task images.
But I don't think that anybody but Old Dog will use this method to create designs.

I am also positive to defining a second task image.....perhaps named icon.png or similar to be located in the plugin skin directory, so it in the future would be possible to create skins with dual "task images" like Meedio HDeeTV or the clone Nonafu at MP.
This image should be a "square" eg 64x64 or 128x128, so it could be used in the plugin skin itself with a "theme" or in the main menu if a skin/XML designer wants to use it.
(Dottore has used "icons" in the sub menu skins)