Community skin project

[Old Dog]

I'll stand by my post, let the community identify our starting point, one screen at a time. We create two xml files, one devoid of graphics, the other with graphics for Blue.

Sassari is too new. Also, converting it from 16:9 to 4:3 is another task that may lead to problems. We don't need another task at this time.

KISS!

Regards,
Old Dog

[Old Dog]

**DaPhatty Chimes In**

I nominate Contour as the 4:3 standard and Sassari as the 16:9 standard.

I have never used Contour myself. Indeed I have only spent a few minutes looking at it. I do know that many people from the community contributed to it's implementation and that it gets rave reviews for viewing ability.

I will be surprised if several plug-in and core xml files from Contour are not selected by the community as best implementation.

realize of course that no matter what skin the screen comes from originally, we will create a Blue "look" for it.

Regards,
Old Dog

[Old Dog]

What skin has the best core TV Guide layout in terms of usability?

(not necessarily the prettiest)

[sub]

I'm pretty happy with MixMan's BaseSkin layout. He's done a lot of work to make sure things are appropriately sized for non-english speaking friend. Some of those European translation are pretty long.

[sub]

You guys might not want to press ahead too far before the next release. I'm adding a few skinning features to improve things. They're only really additional tools, but I can see them playing a useful role. Some of these that have popped to mind in recent days...

1/ standard fonts, allowing TextStyles to be defined without a font family specified, or another TextStyle to be specified to extract this info from. For example, a plugin requires a specific TextStyle defined called "StationName". In it's skin.xml, it may then refer to some standard font for its type face and font style, which is defined base skin.xml.

2/ colour that reference other colours. Each plugin's skin.xml usually contains many tags that directly specify colours. I'll add a mechanism which allows these to reference some other colour defined in baseskin.xml. For example, your could add a colour called 'ScreenTitle' which is refered to by the DrawText "Screen Title" element in each plugin. Another example might be, changing the bulk of TextStyle elements to all reference some newly defined 'StandardTextColour' in baseskin.xml, allowing all the text colours in all the screens to be changed in one place. Same could be done with selection colours - a specific skin.xml might draw a list selection using a RoundedRect with the colour referencing some base skin 'StandardListSelectionBackground' colour.

3/ CompositeImage can draw another CompositeImage. If you have common elements like a file selection list that might occur on half a dozen screens, you could define this in the BaseSkin.xml and have the specific skin.xml files just to a <DrawCompositeImage> for this common element. The implementation in BaseSkin.xml might use <DrawImage> or <DrawRoundRect> or whatever.

You might need to use your imagination a bit to see the full extent of how these will be used.

These changes will make it much easier to standardize fonts/colours/images in the BaseSkin.xml, and can conveniently added to existing plugins with their authors needing to make changes.

[sub]

I would like a new user defining their own skin to only have to a couple of simple tasks along the lines of:

1) Create new skin directory with the name of their skin.
2) Copy the BaseSkin.xml and preview.jpg from the standard skin into their new directory.
3) Create a new Background.jpg for the background they'd like to use
4) Edit BaseSkin.xml to customise the look of the buttons (may be images or XML), and to set the colours and fonts they'd like to be used.
5) Start the application and update the preview.jpg to what their skin really looks like

From then on, they would not need to maintain that skin, even as future versions of plugins are made etc.

[McBainUK]

I'm adding a few skinning features to improve things.

WOW, this stuff looks great. Can't wait to start playing .

Edit:

3/ CompositeImage can draw another CompositeImage. If you have common elements like a file selection list that might occur on half a dozen screens, you could define this in the BaseSkin.xml and have the specific skin.xml files just to a <DrawCompositeImage> for this common element. The implementation in BaseSkin.xml might use <DrawImage> or <DrawRoundRect> or whatever.

Would the BaseSkin.xml <DrawImage> do scalling? For example if you had a 400,300 "FileList" element defined in BaseSkin.xml, would a <DrawImage name="FileList" size=300,100> in a plugin skin.xml draw the FileList element the scaled to fit 300,100 ?

[Old Dog]

You guys might not want to press ahead too far before the next release. I'm adding a few skinning features to improve things. They're only really additional tools, but I can see them playing a useful role. Some of these that have popped to mind in recent days...

1/ standard fonts, allowing TextStyles to be defined without a font family specified, or another TextStyle to be specified to extract this info from. For example, a plugin requires a specific TextStyle defined called "StationName". In it's skin.xml, it may then refer to some standard font for its type face and font style, which is defined base skin.xml.

2/ colour that reference other colours. Each plugin's skin.xml usually contains many tags that directly specify colours. I'll add a mechanism which allows these to reference some other colour defined in baseskin.xml. For example, your could add a colour called 'ScreenTitle' which is refered to by the DrawText "Screen Title" element in each plugin. Another example might be, changing the bulk of TextStyle elements to all reference some newly defined 'StandardTextColour' in baseskin.xml, allowing all the text colours in all the screens to be changed in one place. Same could be done with selection colours - a specific skin.xml might draw a list selection using a RoundedRect with the colour referencing some base skin 'StandardListSelectionBackground' colour.

3/ CompositeImage can draw another CompositeImage. If you have common elements like a file selection list that might occur on half a dozen screens, you could define this in the BaseSkin.xml and have the specific skin.xml files just to a <DrawCompositeImage> for this common element. The implementation in BaseSkin.xml might use <DrawImage> or <DrawRoundRect> or whatever.

You might need to use your imagination a bit to see the full extent of how these will be used.

These changes will make it much easier to standardize fonts/colours/images in the BaseSkin.xml, and can conveniently added to existing plugins with their authors needing to make changes.

You might consider an Alias directive for 1 & 2.

Examples:
<Alias name="BigFont" alias=MyScreenFont">
<Alias name="Blue" alias="MyScreenFontColor">

[Fatman_do]

I would like a new user defining their own skin to only have to a couple of simple tasks along the lines of:

1) Create new skin directory with the name of their skin.
2) Copy the BaseSkin.xml and preview.jpg from the standard skin into their new directory.
3) Create a new Background.jpg for the background they'd like to use
4) Edit BaseSkin.xml to customise the look of the buttons (may be images or XML), and to set the colours and fonts they'd like to be used.
5) Start the application and update the preview.jpg to what their skin really looks like

From then on, they would not need to maintain that skin, even as future versions of plugins are made etc.

Sounds great.

Having baseskin.xml handle "what things look like" seemed to be the key. It looks like your explanations go even further than this by having some sort of "lookup" and "grouping" method.

This may very well solve Reboot's Riddle..........

[Jeff]

WOW, this stuff looks great. Can't wait to start playing .

Edit:

Would the BaseSkin.xml <DrawImage> do scalling? For example if you had a 400,300 "FileList" element defined in BaseSkin.xml, would a <DrawImage name="FileList" size=300,100> in a plugin skin.xml draw the FileList element the scaled to fit 300,100 ?

With respect to scaling, I think it would be useful if you could specify in drawimage if the image should be stretched/squished to fill the specified size or if it should be done while maintaining the aspect ratio. Right now it fills the specified size, but some images (like task images) area not the same in all skins and look very bad when stretched too far. In this case I think it would be better if the skin could specify to maintain the aspect ration and the then to specify the alignment of the image withone the alloated space (e.g., left, right, centered).

Jeff