Community Skin 3.0 Open development thread.

[Fatman_do]

Along the lines of the _CoreImages change and moving the SkinPlugin's storage files to the plugins folder. I imagine this could work....my syntax may be off...

Modify 4:3 Community, 16:9 Community-WS and 1.0.x Community xml files to look for "..\plugins\skinplugin\_CoreImages\Button_Selected.png"

If all variants can be trained to look in one folder for the images, we are ahead of the game.

[edit: Noble idea, but after further thought, this blows the xml portability with other skins out of the water]

[Fatman_do]

....my syntax may be off...
"..\plugins\skinplugin\_CoreImages\Button_Selected.png"

I have successfully gotten this to work by using "..\..\..\plugins\skinplugin\_CoreImages\WhateverImage.png" in the baseskin.xml and menu skin.xml file.

Could this be an avenue of approach?

It could just as easily be a different folder.

[edit: Noble idea, but after further thought, this blows the xml portability with other skins out of the water]

[Fatman_do]

A classic example of the easiest skin change would be to use all the xml's in the blue skin folder. "My Skin" can then contain only a "My Skin\_CoreImages" and "My Skin\Menu" folder, and a "My Skin" baseskin.xml file.

You can copy "gbpvr\skin2\Community" as "gbpvr\skin2\My Skin".
Delete all but those two folders and baseskin.xml file.
Set your skin to My Skin and it should work straight away.

errr, or not.

That is/was the fallback method under the old UI.

The new UI looks for the same skin name in the gbpvr\skin folder for fallback. (as a request by me for backward compatibility with legacy skins).

[Jeff]

Along the lines of the _CoreImages change and moving the SkinPlugin's storage files to the plugins folder. I imagine this could work....my syntax may be off...

Modify 4:3 Community, 16:9 Community-WS and 1.0.x Community xml files to look for "..\plugins\skinplugin\_CoreImages\Button_Selected.png"

If all variants can be trained to look in one folder for the images, we are ahead of the game.

[edit: Noble idea, but after further thought, this blows the xml portability with other skins out of the water]

Yes, that's what I was thinking when I suggested moving things to coreImages. If MixMan uses the same naming convention (which I think should like like whatever sub has picked for blue) then we may get to the point where simple skins (like weather) need little if any chnage to move to a new skin.

Jeff

[Fatman_do]

Ok, just as I stated in my edits above, skin2 xmls shouldn't have crazy path descriptions because that would break Jeff's request with path/naming conventions to be the same as blue.

I can retroactively rename the stuff in the legacy Community skins to adopt the new naming convention.

[McBainUK]

adopt the new naming convention

Sorry, I''m getting confused here. What naming convention? skin2/Blue's?

[Fatman_do]

Per this request.

Since the community skin needs to change for pvrx2 anyways, how about changing the location of images from CommonImages to _CoreImages. Also, at the same time I think the CommunitySkin should use as many of the naming conventions from the new Blue skin as possible. By doing so some simple skins made for the new blue skin should become CommunitySkin compatible automatically. This would also make the CommunitySkin more compatible with the skins made by MixMan.

Jeff

So far this hasn't been necessary with any Pvrx2 skin, since the baseskin.xml file is doing all the work. Weather and MusicLibrary3 work without any changes.

[Graham]

The story so far (as I understand) ...

TextStyles and other globals used in .XML files

The current situation is that a reference to, for example, ListViewItems will be resolved by looking in this .xml file, then the baseskin.xml for this skin, then the baseskin.xml in the blue skin.

The options include having a "base" skin folder (that is empty in the GBPVR distribution) and using \skin2\base\baseskin.xml as the global repository. This would ensure that the blue skin does get "cluttered" and can be used, for example, for debugging (e.g. if some problem goes away when blue is used then it must be a skin problem).

Task Images -- that is task.png in a folder with the same name as a plugin

Currently \skin2\Community\Menu\skin.xml contains this:

<CompositeImage name="TaskImage" size="45,62">
<DrawImage filename="@taskImage" loc="0,0" size="100,100" fixedAspectRatio="true" />
</CompositeImage>

The default value for @taskImage would seem to be task.png in a folder with the same name as a plugin.

The options include staying as now. To use YourSkin taskimages with MySkin may involve copying lots of task.png files to and fro. There may never be a unique Little Blue Man, for example, for each of 20 or more plugins and the same task.png will need to be duplicated in lots of folders.

Another option might be to handle taskimages in the same way as other images.

Buttons and wotnot -- images that are not task images

The current situation is shown here:

<DrawImage filename="..\_CoreImages\Down.png" loc="15,10" size="70,80" />

The .png can be anywhere and the filename= points to the location of the .png.

The options include staying as now. It may be that a convention can be agreed and Down.png will be in one of three places -- the same folder as the .xml, the _coreimages folder for this skin, a global _coreimages folder in, for example, a \skin2\base\ folder.

A second option may be to automate the above. the .xml would contain filename="Down.png" and folders would be searched in order until Down.png is found. It may be that the global folder could contain MySkinDown.png and YourSkinDown.png.

A third option may be all of the above. A reference to Down.png would trigger an automatic search. A reference with a \ in it, such as ..\_CoreImages\Down.png would expect the image to be located as advertised.

Legacy plugins

The current situation is that when I am using MyLegacyPlugin with MySkin, there should be a MyLegacyPlugin folder in the \skin\MySkin folder.

It may be that this provides maximum compatibility with legacy plugins and does not need to change.

Legacy Skins

Much effort and skill has gone into developing a lot of skins that cater for a lot of legacy plugins.

An option might be create a "frozen" version of each of these. There might be a \skin\MySkin with .xml that defines a generally acceptable collection of buttons and whatnot. It may be that extracting the many themes from the Community Skin to create these legacy skins is not too much of a chore for a man of stamina and good character.

SkinPlugin

The options may include variable driven skins. The SkinPlugin would set a value in a vars.xml file. The vars.xml might contain Buttons=Large or Buttons=Small. The .xml file might contain definitions for large buttons and for small buttons. Buttons would be displayed based upon the value the Buttons= variable.

Another option might be for the SkinPlugin to directly edit the .xml files. The .xml file might contain definitions for large buttons and for small buttons. The SkinPlugin would alter the .xml to, for example, comment out the xml for small buttons and enable the xml for large buttons.

Skins might be SkinPlugin compatible or not. A skin might have a comment in its \menu\skin.xml that is something like <!-- skinplugin=Y -->. Any skin that is missing this value would be ignored by the SkinPlugin.

Apologies in advance for anything that I haven't thought through. Have I overlooked or misunderstood anything?

Graham

[McBainUK]

the same task.png will need to be duplicated in lots of folders.

This is because task images are handled by individual plugins and not the GBPVR skin mechinism.

[Graham]

This is because task images are handled by individual plugins and not the GBPVR skin mechinism.

Ooops. It may be that I will eventually get my head around task images.

Is it right that the task image is the task.png that sits in the \skin\blue\MyPlugin folder and is displayed in the initial main menu as I scroll to MyPlugin in the menu?

What handling of task images is done by individual plugins?

Thanks

Graham