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

[Old Dog]

One desirable feature of any future skinning system is the ability to modify the skin on-the-fly, i.e., within GBPVR.exe.

I believe in the baseskin.xml concept, but see a need to modify the file on-the-fly and have the changes become immediatly effective.

Just this requires a united effort including sub, plug-in developers, and skinners. Can we achieve this?

[sub]

I have been looking into unloading and reloading plugins to force the plugins relinquish their locks on image files they're holding, and to force them to pickup the new skin. Hopefully, yes, we'd be able to reload on fly. When will I add this? I dont know - some time in a future release (probably not v0.98).

[Old Dog]

BTW, I started thinking on these issues about nine+ months ago. So far I have been able to focus on things I could accomplish on my own.

While I haven't implemented everthing that I could, I now find myself wishing for things that require cooperative and probably transitional development.

Have you read the wishlist today?

[MixMan]

I have started to write on a suggestion to a guideline, things to consider to when making a default skin and skin guideline to plugin developers and skinners. The optimal is if a plugin skin would work with all resolutions a baseskin would have for image sizes and text sizes.
Could this be automated with some kind of a scale facor for low res plugins?. This is something Dottore ran into with Olbia and will do with Sassari.
I don't know how to make a skin with 1024x768 and get the plugin skins yo work without reskinning them.

I am sure that this community can create/provide images that you Sub, could use in a default image based skin for GBPVR.

[Fatman_do]

Just got home and it is almost midnite here. I will look at green and digest everything here tomorrow that I missed today and may miss while snoozing.

Cheers

[Fatman_do]

Another change that might be worth making, is allow the baseskin.xml to define which skin should be the standard skin that missing elements are inheritted from, rather than assuming its always blue. This way you could have a series of skins based of sassari, or based on blue etc. Sort of a family of skins. This way only the few parent skins actually need to be actively maintained, and those derived skins pickup the changes for free.

Ok before going off to bed here...

I think this might be unnecessary if a new image based standard comes into being. If this next gen skin is the new standard, most skinners will just embellish it and add their own personal touch. If a new plugin's skin is not found, the new standard would at least look decent due to it using images that are custom skin specific.

The problem I see with the baseskin.xml pointing to another skin to fall back on, you have to rely on those parent skins being current and up to date. If a derived skin looks to its parent (sassari as in your example) and that skin has not yet added a new plugin, does this then fall back again to blue?

Actively maintained skins are still usuallly behind at one point or another.

I don't know, just a red flag when I read it. It might make sense to me in the morning.

[sub]

If a derived skin looks to its parent (sassari as in your example) and that skin has not yet added a new plugin, does this then fall back again to blue?

No I probably wouldnt bother. Sure, the same problem can still exist then, but I think it'll solve the problem for majority of skins, where users only want a slight variation on an the standard skin.

I can see your concern, but I think there may always be the need for more than one standard skin, for example widescreen vs 4:3, which is why I have sassari as an example. There is no easy alternative to this. It may not be sassari, but there may need to be a standard widescreen skin.

By at least providing this facility, then you're giving the option for it to be used, allowing creative types like dottore to give us beautiful creations that dont look exactly the same as other skins, and for other skins to be derived from those.

I dont care if we dont solve every potential problem, its a big improvement on what we're seeing with the many old dead skins on the wiki.

[Fatman_do]

No I probably wouldnt bother. Sure, the same problem can still exist then, but I think it'll solve the problem for majority of skins, where users only want a slight variation on an the standard skin.

I can see your concern, but I think there may always be the need for more than one standard skin, for example widescreen vs 4:3, which is why I have sassari as an example. There is no easy alternative to this. It may not be sassari, but there may need to be a standard widescreen skin.

By at least providing this facility, then you're giving the option for it to be used, allowing creative types like dottore to give us beautiful creations that dont look exactly the same as other skins, and for other skins to be derived from those.

I dont care if we dont solve every potential problem, its a big improvement on what we're seeing with the many old dead skins on the wiki.

Yes, not every problem is going to be addressed. I can see that idea working now if there are 4:3 and 16:9 standard skins. I just was cautious about the mechanism causing more problems than it fixed. I suppose it adds options, which I am always in favor of. If there is a problem, then the ability to assign a different parent skin fixes it.

[Fatman_do]

How well does this work with MPV's?

I cannot answer that. I have none.

[dottore]

there's one big problem with widescreen-skins and skins that don't use 720x480: some of the plugins just don't support other resolutions....

take this into consideration (this is why i didn't skin xrecord properly for olbia and why i surely won't skin it for sassari).

oh, by the way: i would be happy in creating just graphics without bothering about positions, sizes, gaps and so on. this means: the gap between two buttons would have to be defined in some sort of baseskin.xml. the size of a button would be dynamic, defined by the size of the button-image. this won't work, since every element in gbpvr is a composite image (good idea)..... it is not that easy to standardise the whole thing.

we could have a standard-image-based skin, but what about skins, which want to use more rows in the recordings-screen, than that standard-skin? just as an example....