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

[Fatman_do]

I don't think that anyone have really understood how flexible the BaseSkin/Theme concept is.

I made a "plugin skin" for Torque and ContourHC for the ThemesManager.
This will allows Contour users to change between the different color designs that Contour has. On the fly all MCE2 skin xml designs will get Contour look.

The BaseSkin concept will work with any skin design.
So all plugin developers. Have a look at the BaseSkin and tell me what functionality you miss.....and I will add it.

ThemesManager for ContourHC designs - Uploaded it to the Wiki
http://gbpvr.com/pmwiki/uploads/Skin/Con...Themes.zip

I understand your concepts fully, no real magic here. The solution you present here is fine if ContourHC is re-written to use images. Otherwise, all this is is a themepack for BaseSkin and not a solution for ContourHC. ContourHC would need to be rewritten to use images instead of xml for selections, listviews, buttons, popups, ect. to be able to use plugin skins developed with images.

The BaseSkin concept will work only with skin designs that are designed using it. It is a good method for future skins. Just current xml skins are at a disadvantage. There is nothing that can be done about it however.

Moving foward with an imaged based skin design wouldn't be that tough. There can be "stock" images that look like 'blue' that are swapped out for xml code that developers can access. There would be almost no difference for the plugin developer. No images they need to create, a default image library set with no frills would be available. A 1-to-1 changeout of xml for images can be done by the community or the developer in little time.

Anything beyond a basic look is up to a skinner to add, reposition, ect. With a standard image set, at least the 'standard' plugin skin will be close.

Don't get me wrong, I am in favor of moving 'foward' if that is what is needed to be done. In fact, I support the idea. I just was indicating that to move foward, some get left behind.

If sub or plugin authors do not wish to jump on this idea yet, the community here can surely maintain and develop this idea (I would be willing to do this, can't have to many pokers in the fire). Like I stated before, a swap-out for images would not be tough to do. I think to be fair, help should be offered to all skins out there that wish to move to this design scheme as well.

[Old Dog]

A new 'Blue+' that is based on images instead of xml, yet looks nearly identical?

This will be a design that image based skinners can use, and would "drop in" well if the skin follows that structure.

Note: I am currently extending Appearance Manager support in Blue-AM. In the extension, I am creating image files for all of the plugins. As a side effect, I am creating Blue XML files that are image based.

I'd be faily happy with looking at a standardised type skin, especially if we could get up to the media portal/meedio skin changing on the fly.

I thought AM did this and more. No?

____________________

I can't but have noticed that no one in this thread has mentioned Appearance Manager.

I think that Appearance Manager has all of the attributes you guys are describing and some you haven't verbalized. For example, from the begining, the AM skinning system was designed to support plugins weather they are image based or not, or somewhere in between.

Also, I only no of one skinner that is trying to use AM, and he seems to be hesitant to use AM as intended.

Why?

What is it about AM that skinners don't like?

[Fatman_do]

Note: I am currently extending Appearance Manager support in Blue-AM. In the extension, I am creating image files for all of the plugins. As a side effect, I am creating Blue XML files that are image based.



I thought AM did this and more. No?

____________________

I can't but have noticed that no one in this thread has mentioned Appearance Manager.

I think that Appearance Manager has all of the attributes you guys are describing and some you haven't verbalized. For example, from the begining, the AM skinning system was designed to support plugins weather they are image based or not, or somewhere in between.

Also, I only no of one skinner that is trying to use AM, and he seems to be hesitant to use AM as intended.

Why?

What is it about AM that skinners don't like?

Ok I know my skineffects execution in my design is weak, but that is another topic. I see limitations with some execution based on what I see in certain plugins, plus I haven't even finished skinning xml wise to focus on images. Other than that, I would have to say I use it exactly as intended (I have not seen anything that would indicate otherwise).

I am not advocating Themepacks or AppearanceManager (or one over the other). Nothing about moving to an image based design excludes or champions either method. Image changing on the fly is a by-product of the switch in the first place. Feature specific images of each method will be excluded from this change (I would hope). Button image names are not important to AM (we are talking plugin skins here) so that is not an issue. AM only has requirements for the main menu if I remember correctly. Those should be considered if this is a stand alone skin as well.

Images like "se.png" or "..\whatever_logo.png", "..\background_mask.png", "..\Button_close.png" ect., are extras in my opinion. If it is not a 1-to-1 swapout from 'blue', it is not needed.

This idea needs to be a stripped down basic skin. Bells and whistles can be added by the skinner.

Yes AM can work with xml skins (I created a ContourHC skin that only changed backgrounds since buttons are xml), but the idea here is a move to images for all screen elements. This way plugin "X"'s skin can be dropped into skin "Y" and since it will use common images from skin "y", it will look at least somewhat like the rest of the skin. Fancy bells and whistles will be missing, but those are easiest to add.

I think all we are talking about (or at least should) are button images, "List Backgrounds", "List Selections/Non-Selections (short and tall)" and "Popup Backgrounds". Icon seclection images are usually image based now anyway.

Can anyone think of anything else that isn't "image bloat".

[Old Dog]

...but the idea here is a move to images for all screen elements...

I think all we are talking about (or at least should) are button images, "List Backgrounds", "List Selections/Non-Selections (short and tall)" and "Popup Backgrounds".

I think I can add to your observation just a little.

All (graphical) screen elements can be divided into two catagories, static and dynamic. Static elements are displayed when the plugin is activated and do not change. Dynamic elements change as a result of the user's interaction with the plugin.

The static elements, in combination with the xml code are what define the character of the skin.

The dynamic elements such as button images, "List Backgrounds", "List Selections/Non-Selections (short and tall)" could be shared by many skins.

Is this okay?

[Fatman_do]

I think I can add to your observation just a little.

All (graphical) screen elements can be divided into two catagories, static and dynamic. Static elements are displayed when the plugin is activated and do not change. Dynamic elements change as a result of the user's interaction with the plugin.

The static elements, in combination with the xml code are what define the character of the skin.

The dynamic elements such as button images, "List Backgrounds", "List Selections/Non-Selections (short and tall)" could be shared by many skins.

Is this okay?

That is pretty much what I was getting at. The static graphical element right now is just background.jpg, which already is the defacto standard.

"List Backgrounds" can be considered static, but there are a number of plugins that use these as dynamic elements.

The plugin skins would not contain the common images, these are supplied by the skin it is placed into. So then you could place that plugin into "SkinX" and your screen elements will look like the rest of the skin. All you would have to do as a skinner is tweak the layout and add any extras that your skin would require (se.png, changing the menu title position or method it is created, ect.).

You wouldn't need to change the xml color values for popups, list backgrounds, ect, since they would be coded as images that you already produced using standard names.

[Old Dog]

That is pretty much what I was getting at. The static graphical element right now is just background.jpg, which already is the defacto standard.

"List Backgrounds" can be considered static, but there are a number of plugins that use these as dynamic elements.

You are so "right on the money!". Ideally, it would be best to gather all of the static graphical elements and combine them together into a single image file.

Now I will suggest a good reason not to do it exactly the ideal way.

If instead of a single image file, if we decide to use two files, we can use one for the static graphical elements as we have described above, and we can use the other for primary color selection.

This is the approach I advocate in AM. The first image below, is the static skin, "se.png". The second image shows the static skin on top of the color selection file, "Background.jpg".

Note this is why I do not advocate placing static skin elements in the "Background.jpg".

[Fatman_do]

You are so "right on the money!". Ideally, it would be best to gather all of the static graphical elements and combine them together into a single image file.

Now I will suggest a good reason not to do it exactly the ideal way.

If instead of a single image file, if we decide to use two files, we can use one for the static graphical elements as we have described above, and we can use the other for primary color selection.

This is the approach I advocate in AM. The first image below, is the static skin, "se.png". The second image shows the static skin on top of the color selection file, "Background.jpg".

Note this is why I do not advocate placing static skin elements in the "Background.jpg".

But you see, I would use list backgrounds in a "standard" as dynamic because those would be something I would rather place on top of backgrounds (no skin that I know of use these in the background image). Then locations can be moved and resized by xml code (this mimics blue as well). Look at the plugins (off the top of my head), RssReader, Calendar and MusicLibrary2 as examples that use "list backgrounds" in a dynamic way. A static image for list backgrounds there doesn't work as well. Plus, this puts image creation back onto the shoulders of developers which they would not want.

[Fatman_do]

You should just keep it simple. To much code changing they you'll have to re-do. The standard Search works find. I hardly use it only when I need to have multi-time slots. The XSearch is a bit better but it does the same thing.

Fatman_do you haven't updated to 97.13..?

Btw-Shouldn't this topic be in Plug-in and Skins Support instead.

That is the goal to keep it simple.

No, I haven't downloaded 97.13 on my dev PC or HTPC yet. Not because I did not want to. I worked until 11:00 last night, then got up a 6:00am until 11:00 this morning so I haven't had time. I did download it at work and take a look at it. I plan on doing it shortly, I just need to break away from here for a few hours to do so.

This topic could be in the developers forum as well. We just hijacked this one I am afraid.

[Fatman_do]

Sorry Old dog and MixMan if I come across as a "nay-sayer". That is not my intention, but re-reading my posts, it sounds like it.

[MixMan]

What Reboot said is that skins are not up to date and are not working with the plugins.
The current way of making skins does not work.I would say that 90% on the Wiki are more or less "dead" right now. They don't even work fully with GBPVR core.
What I am saying, is:
Skip the Blue skin as soon as possible.
Dont make Blue skins anymore.
Plugin developers - do not make more than one skin.
Define a standard skin that uses images.
Define image naming and location of the images.
Just make one skin "Standard" skin....that is "general", that can be used with all skins......like the Blue can today.
What I have tried to say....there is a skin that has all this already has the features .....BlueMCE2.
Rename this to "standard"......so you and users dont think of the graphic design.
What all skin designer do is keep their images in the resources folder. This would not to be to hard to agree on ?
The issue is naming of the images and location of the images.
Don't make it more difficult than it is.