Community Skin 3.0 Open development thread.

[Graham]

The good news -- I'm off on my holidays soon and will leave you all in peace.

The bad news -- I have a couple more observations that will demonstrate my poor understanding of how all this works (but I'll feel better if get it off my chest).

Would it be feasible for the skinplugin to use "move" instead of "copy" to get the right files into the right places when changing , for example, a theme? Files (and, maybe, folders) could contain a value (as a comment in an .xml file or a identifier.id file in a folder) that would allow a "move" back to the skinplugin repository before the move of a new theme (ar whatever) into the skin folder. The benefit would be a more responsive skinplugin since nothing actually moves when a file of folder is "moved". I'm not sure which, if any, files have their content changed by the skinplugin. I can see that a move is not pratical if the content of the file also gets changed by the skinplugin.

The skinplugin allows me to select the number of lines that I want to see in my TV Guide (or Listing, etc). I'm guessing that this is implemented by copying the relevant .xml file from here to there. It may be that all of the several versions of the, for example, TV Guide .xml could be merged into a single file as blocks and xml comments could be edited by the skinplugin to activate the require block of xml. For example:

Start comment
5 line guide XML
6 line guide XML
End comment
7 line guide XML
Start comment
8 line Guide XML
End comment

The above could be changed to activate a 6 line guide by editing (i.e. moving) the start and end comments.

It may be that this technique could also be applied to other "edits".

Thanks

Graham

[Fatman_do]

Would it be feasible for the skinplugin to use "move" instead of "copy" to get the right files into the right places when changing , for example, a theme? Files (and, maybe, folders) could contain a value (as a comment in an .xml file or a identifier.id file in a folder) that would allow a "move" back to the skinplugin repository before the move of a new theme (ar whatever) into the skin folder. The benefit would be a more responsive skinplugin since nothing actually moves when a file of folder is "moved". I'm not sure which, if any, files have their content changed by the skinplugin. I can see that a move is not pratical if the content of the file also gets changed by the skinplugin.

The skinplugin allows me to select the number of lines that I want to see in my TV Guide (or Listing, etc). I'm guessing that this is implemented by copying the relevant .xml file from here to there. It may be that all of the several versions of the, for example, TV Guide .xml could be merged into a single file as blocks and xml comments could be edited by the skinplugin to activate the require block of xml. For example:

Start comment
5 line guide XML
6 line guide XML
End comment
7 line guide XML
Start comment
8 line Guide XML
End comment

The above could be changed to activate a 6 line guide by editing (i.e. moving) the start and end comments.

It may be that this technique could also be applied to other "edits".

Thanks

Graham

You somewhat lost me there but I think I can see where you are going.

You could have built in sections commented out.

<!--Option1-->
blah
blah
blah
[COLOR="YellowGreen"]<!--OptionEnd-->

<!--Option2-->>
<!--
blah
blah
blah
-->
<!--OptionEnd-->


<Option3>
<!--
blah
blah
blah
-->
<!--OptionEnd-->[/COLOR]


The skin.xml file reads as normal, What is between <!-- --> is ignored, and does the option 1 stuff. Lets say a user changes to option 2, it would look like..

[COLOR="YellowGreen"]<!--Option1-->
<!--
blah
blah
blah
-->
<!--OptionEnd-->

<!--Option2-->>[/COLOR]
blah
blah
blah
[COLOR="YellowGreen"]<!--OptionEnd-->


<!--Option3-->
<!--
blah
blah
blah
-->
<!--OptionEnd-->[/COLOR]

You could do this with the main menu with button definitions for left side, centered, or right side already pre-defined.

[Fatman_do]

Yet another idea is to add <commonimages> for all the used images defined here: http://gbpvr.com/pmwiki/pmwiki.php/Devel...munitySkin

As now what would happen when the theme/SkinPlugin wanted to changed the image for "IconView_FolderVideo", for example?

That won't work because all <CommonImages> are drawn only full size of the composite image. I have tried that with the Folder icons already.

[tipstir]

Just use what sub has and reverse engineering it, so you really have the time to START all over again.. I got to squeeze a few hours just to make one new skin theme appear..

[Fatman_do]

With PVRX2 screens and plugins the SkinPlugin would be able to edit the baseskin.xml file directly, changing the paths defined in the common image tags and the colour, style & size of a (limited) set of textstyles.

This would work well for my idea to group buttons and List Selectors instead of the user needing to pick each and every one.

<CommonImage name="ListViewNormalItemBackground">
<DrawImage filename="..\_CoreImages\ListSelectors\Transparent\List_Normal.png" loc="0,0" size="100,100"/>
</CommonImage>
<CommonImage name="ListViewSelectedItemBackground">
<DrawImage filename="..\_CoreImages\ListSelectors\Black\List_Selected.png" loc="0,0" size="100,100"/>
</CommonImage>
<CommonImage name="ListViewSelectedInactiveItemBackground">
<DrawImage filename="..\_CoreImages\ListSelectors\Green\List_SelectedInactive.png" loc="0,0" size="100,100"/>
</CommonImage>

Plugin xml's really cannot take advantage of a directory structure for bonus images like Folder.png since they will look only in CoreImages by default from the blue skin version.

My concern is how this would effect legacy plugins and theme application. By simplifying it like this not using the coreimages folder in the CSkin it may cause trouble. One idea is to have 2 sections to the SkinPlugin - one to apply themes and edit fonts etc for new-style plugins. And another which continues to support the legacy plugins and the same manner as now. The question is then if you apply a theme in the new UI, a GBPVR.exe theme will also need applying to keep the old plugins looking similar.

---------------------------------------------------------
My current thoughts are to continue to use the coreimages folder copy files into the skin/community/coreimages and skin2/community/coreimages, and I will possibly look into adding a method of saving themes-even if it means save to folder. Textstyles would be updated directly, only effecting the Skin2 baseskin file.

---------------------------------------------------------
As you can see I have been thinking how things will work and what the expericance of using the SkinPlugin should be like and I have more questions then answers.... Any comments/suggestions warmly recieved

You could copy the Coreimages folder, Menu, baseskin.xml and possibly tvguide folder to a folder under Themes called MyTheme. That will always be selectable at the theme level.

For legacy, I could always hard-wire the legacy version to look in skin2's CoreImages folder if that helps.

[Fatman_do]

Just use what sub has and reverse engineering it, so you really have the time to START all over again.. I got to squeeze a few hours just to make one new skin theme appear..

Not exactly the same thing being discussed here TipStir. We already have a compatible version of the skin. We are working on making it better.

[McBainUK]

You could copy the Coreimages folder, Menu, baseskin.xml and possibly tvguide folder to a folder under Themes called MyTheme. That will always be selectable at the theme level.

This is what it will have to-do. Obv changes in baseskin or menu will break the saved theme, but (at the moment) I cant see a way around that and I know fatman_do tends avoid changing baseskin contents anyway as it effects all themes.

For legacy, I could always hard-wire the legacy version to look in skin2's CoreImages folder if that helps.

This would half the amount of copying. For legacy it the SkinPlugin offers a baseskin/fonts option which selects a baseskin from the range available and copies the file into skin/community/ (like it always has done). A theme can specify a <LegacyBaseskin> editable skin item which would be choosen to best match the skin2 baseskin fonts and colours etc.

That won't work because all <CommonImages> are drawn only full size of the composite image. I have tried that with the Folder icons already.

Bugger. As it isnt possible to have all images work as <commonimages> it doesnt make sense for there to be a mixture of filecopy and direct edits so my reccomendation is to have the SkinPlugin work as it does now and copy files - and change the appliyer exe to a nice shiny windows form so it hides this stuff from the user. As Graham put it - "out of sight out of mind".

Commented sections of files
I see a problem presenting the user with a preview image and making the SkinPlugin parse the XML file for all available options. The MS XML reader won't be able to help with commented text so will have to do it manually! Which increases complexity and likeleyhood of errors - something we all want to avoid.

Fonts and colours
I can see a benifit in editing these directly in the (skni2) baseskin.xml. If a list is made of items/textstyles that need to be set and what kind of options (font, size colour?) then I will add this into the SkinPlugin.

Green is globally set, and Blue is globally set.

Bit confused, did you mean something different here?

-------------------------------------------------------
Once again, comments welcome...

[Fatman_do]

Re: my comments on globally set.

Bit confused, did you mean something different here?

Lets say there is an option for changing text size under icons, and a user wants to change the size to 13, those of that color I marked would need to be changed.

[McBainUK]

So if, through the SkinPlugin, the user changed Icon View Text to size 14 then both these lines would be changed from:

Code:

<TextStyle name="IconViewItems" color="Normal" size="12"/>
<TextStyle name="IconViewFolders" color="Header" size="12"/>

to:

Code:

<TextStyle name="IconViewItems" color="Normal" size="14"/>
<TextStyle name="IconViewFolders" color="Header" size="14"/>

Correct?

[Ted the Penguin]

Commented sections of files
I see a problem presenting the user with a preview image and making the SkinPlugin parse the XML file for all available options. The MS XML reader won't be able to help with commented text so will have to do it manually! Which increases complexity and likeleyhood of errors - something we all want to avoid.

well, instead of having them commented you could nest them inside something that GBPVR will ignore, make all the tags that you want as selectable options subtags of say <theme1> and <theme2> then when those are selected, just copy their values over the values of the global tags... does that make sense? if not I can clarify more.