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

[McBainUK]

It effectively just means calling the appropriate constructor on the SkinHelper class. I described it about six months back in this post: http://forums.gbpvr.com/showpost.php?p=8...ostcount=1. See the section in that post titled 1) Using the default skin.xml files

I wasnt aware this was actually implemented. Tested it by making the required change to my gmail plugin and deleting its MCE2 sub folder skin. Loaded up GBPVR and...walla...it loaded the blue skin. Good work

I posted most of my thoughts a few pages ago. There seems to be lots of people pulling in different directions though, trying to include other problems under the same umbrella. I think this thread seems to be trying to solve too much. If I did this all the time, I'd get nothing done.

I think what it has shown that making a new skin should be a community project. See post #119. Don't mean to play teacher but if Mixman, Fatman , Old dog and any others can write A SINGLE POST to a new thread in the Developers forum just outlineing your goals. (eg image based, no text in images so allow translation). Defining what rather than how is a good start. What do yo think? A skin that uses defined image names and greater use of the baseskin (even if this requires greater plugin support - will change my own and if access to source code others too). Images can be swapped out to create different looks - both the BaseSkin system and AM seem to be going the same way - is it possible to have the best of both!? Both MixMan and OldDog have said they would do things differently with their system looking back - now's your chance!

I think daphatty's post should be read. Esp the part about old/retired projects. Some skins/plugins on the wiki that are no longer relevent.

[Old Dog]

Would you like to see an image based version of blue developed and floated out there for a while?

As I mentioned earlier, I have recently completed an image based version of Blue supporting the core, video archive, and weather.

Since it already exists, I will post it when I get home. Then we can tear it apart.

[daphatty]

And which one would you bet on?

I would bet on the pretty interface with base functionality and few if any plugins. From an end user standpoint (i.e. the guy who has to keep WAF levels high) it is more beneficial to have GBPVR look really good while doing the basic things extremely well.

In my case, the day my wife became dependant on GBPVR was the day that supporting multiple plugins ended. (Although she lets me get away with testing the beta releases! ) The list of plugins I use now has shrunk dramatically, mainly because many of the plugins I want to use simply don't work with Contour. The same was true when I was a heavy user of BlueMCE2. I only transitioned/switched to Contour after support for my "must have" plugins was added.

At the end of the day GBPVR just has to work. If I have to chose between

A) a plugin that can read Album Art from ID3v2 tags that only works using the Base Blue skin or

B) using the default music player in Contour,

I'd choose B. Think about it, do you want to listen to the music or look at Album Art?

But I digress. The purpose of this thread is to help make GBPVR "just work" in as many variables as possible. I urge all of you to, unlike the last time, take this effort to the next step and begin developing some standards. I also noticed that the plugin developers haven't really chimed in. Please don't let that stop you. If you build it, they will come.

[psycik]

Most of the plugin developers contributed at the start of the thread, and as it got more skin specific rather than development, probably dropped off.

As long as the standards are logical and do-able from a programming point of view then they will be looked at, enforcement is another issue.

What do I mean by logical and do-able??

The standard image names are the first that spring to mind. From a programs point of view a "list" will normally have "listImage" to correspond. And the listImage can be selected or unSelected Eg. ArtistList uses SelectedArtistListImage and UnselectedListImage - creates lots of tags but is a logical structure that is easy to code (and fairly easy to read).

[tkgafs]

At the end of the day GBPVR just has to work. If I have to chose between

A) a plugin that can read Album Art from ID3v2 tags that only works using the Base Blue skin or

B) using the default music player in Contour,

I'd choose B. Think about it, do you want to listen to the music or look at Album Art?

I have to agree, I have never quite understood the obsession with skins, when I am using gbpvr, for about 98% of the time I am either listening to music or watching a recording in both cases you dont see the skin

yes I like the interface to be attractive but as long as the plugin works who really cares what the interface looks like

Like daphatty I only change to a new skin when a plugin stops working because a new version has come out, at that point its back to blue and wait for the first skin which supports the plugins I use

which out of interest are musiclibrary2, weather, newsfeed, uk cinema listings

Tkgafs

[reboot]

After sitting back, and reading this for a couple of days, it seems there are already some basic skin elements in place, that should work with plugins, providing the plugins are written to take advantage of the stock skins, or default to Blue automatically if a particular skin doesn't have any customization for a particular plugin.
Standardization may be the key.

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.

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?

[nemulate]

Nothing to do with skins mate but Reboot please change your web hosting company as some of us don't like all kinds of popups/programs attempted to be installed!

ta

[reboot]

Heh, I'd almost forgotten all about that page. Nothing's been updated in months, and probably don't work with the current release anyhow.

[Jeff]

One issue on relying on baseskin.xml is that all skins must then have the same baseskin.xml content as the blue skin, since that is the only content that a plug-in can count upon. Putting more in the baseskin.xml file for a partiucalr skin won't bring anything (automatically) to plug-ins and putting leaving out something from the blue version of baseskin.xml will break plug-ins.

Jeff

[Fatman_do]

One issue on relying on baseskin.xml is that all skins must then have the same baseskin.xml content as the blue skin, since that is the only content that a plug-in can count upon. Putting more in the baseskin.xml file for a partiucalr skin won't bring anything (automatically) to plug-ins and putting leaving out something from the blue version of baseskin.xml will break plug-ins.

Jeff

That is true. Another thing to consider is that something that sounds simple like changing all the font sizes in the baseskin.xml file, from "13" to "16" causes problems that there is no magic fix for. Plugin infromation screens are constructed to (usually) give the best fit an proportions with a particular size or another. Dynamic font sizing is not a reality right now.