[Finished] - Skin engine enhancements (themes, guide colors, skin functions, weather settings...) | Page 16

My Suggestion would be:
1. List 1-7 Genre colors in the skin, name them genre_1 to genre_7 (skinsettings.xml)
2. Map the standard/customized genre names (default, documentary, kids, ...) to the genre_1 to genre_7 in MediaPortal.xml
3. Map the EPG Genres to the standard/customized genres either in MediaPortal.xml (or even better in my opinion) in the TV Server Database.

Nice and simple. Why not store the colours along with the genres in the TV database and do this configuration in SetupTV.exe ?

However, we should offer the option to use/not use EPG colouring on an individual basis for clients - so that the colours that will be used are defined centrally on the server, but an individual client has the option to either use the coloured EPG or not!

Mark

The colors used should be modifyable for each skin. I guess colors that are great for one skin (default?) will not work well with the other skins. So the color values should be in skinsettings.xml.

The names "might" be used per client (languages) but can also be stored on the server.

The problem with this is if you change the skin, you have to get used to the different colours, and if skinsettings.xml over-rides mediaportal.xml then there is no way around this (except editing skinsettings.xml, which defeats the point of having these settings configurable.

Whatever we do, it should be as simple as possible for the end user. I'll try to summarise the problems/possible solutions.

1. Right now, the only way to get this configured on a network client is to do the config on the server and then copy the xml files (or parts of them) across to the client.

SOLUTION - ensure that the EPG genres and mappings are done on the server (setuptv.exe) and stored in the TV database. If we don't want the server to enforce colour choices onto the client, then we can choose colours on the client (configuration.exe). So, we separate the two aspects of configuration.

2. Colours defined in the skin over-ride those in MediaPortal.xml, so that changing the colours in MediaPortal.xml (using config) does nothing if colours are defined in skinsettings.xml.

SOLUTION - change this behaviour so that MediaPortal.xml colours take priority over those in skinsettings.xml. However, if you then want to revert back to the colours in the skin, you need an 'import from skin' button in config.

3. Genre names will not be standard for all regions/languages, so that defining them in skinsettings.xml or hard-coding them anywhere will cause problems. This could particularly be a problem on multiseat setups where you change the genres on the server but the client configuration cannot see them (similar to the problem in 1.).

SOLUTION - 'genre1', 'genre2', 'genre3', etc. and then map these in the language files. Since config.exe is not localised (I think) will it be easy to fetch the localised strings and show them correctly in config ? This will mean that we have a fixed number of genres and these will be set by language. However, how many genres do we need? More than 10 and the feature will just be unusable (IMO), If someone really does want to change the name of a particular genre, there is nothing stopping them editing the language file, or we can maybe include this as part of the configuration _at some point in the future_.

I think that if these three issues were able to be resolved, it would be more or less perfect.

Sorry that I am pushing, but with the time we have available, I don't think we have the opportunity to try too many different approaches, and we really need this to be usable in 1.3.0alpha after all of Andy's work. It is sad in a way that this will probably be the only one of Andy's many skin fixes that most users will notice.

Mark

1. Yes, genre definition & mapping should be done on the server
2. OK, get your point. But how about a toggle in config, saying "use skin colors or use my colors"? That way you do not need the import colors button.
3. For easiest maintenance we could also map these on the server (initially) to proper names which would be the default. Later we could add overrides on the client as well. I guess most installations would serve only one language. I would limit this to the logical value of 7 genres + no genre (8 values).

So this is on your server? I have not had time to install on my server yet.

Andy,

How easy would it be to move all configuration to the TV server, and store all EPG colours/genres in the TV database rather than on each client?

Thanks,

Mark

Not easy, and not do-able in the 1.3 time frame (at least by me ;-) Dealing directly with the database will introduce a lot of risk in terms of time to understand, design, complete. I have no idea what the impact of changing the table schema of the tv database would be, nor do I understand the process for upgrading existing database installations. For 1.3 (at least) we'll need to stick with the current architecture. I can make some slight enhancements (including dumping the idea of skin settings being involved at all - just stick with MediaPortal.xml). I'll also rewrite the wiki to make it simple to understand and use.

In principle I could agree that storing genre mapping information in the database makes sense but I'm not on board with putting color information in the database. Color info should live as close to the UI as possible; that's why I initially placed it all in SkinSettings.xml even though I "demoted" it to MediaPortal.xml - and I really only did that because the Configuration tool cannot be made to easily deal with multiple skins (let alone the whole client/server issue).

I'm going to simplify the existing implementation by removing the skin settings override capability (taking skin setting completely out of the design) and reworking the wiki instructions. I know this doesn't solve some of the recently discussed design issues but we're getting close to 1.3 and I want to make this thing as usable as it can be given where we're at.