home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
Area 51 - Testing Area
Skin engine enhancements (themes, guide colors, skin functions, weather settings...)
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="elliottmc" data-source="post: 862367" data-attributes="member: 14268"><p>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.</p><p> </p><p> </p><p></p><p> </p><p> </p><p>Whatever we do, it should be as simple as possible for the end user. I'll try to summarise the problems/possible solutions.</p><p> </p><p>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.</p><p> </p><p>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.</p><p> </p><p>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.</p><p> </p><p>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.</p><p> </p><p>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.).</p><p> </p><p>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_.</p><p> </p><p>I think that if these three issues were able to be resolved, it would be more or less perfect.</p><p> </p><p>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.</p><p> </p><p>Mark</p></blockquote><p></p>
[QUOTE="elliottmc, post: 862367, member: 14268"] 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 [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Area 51 - Testing Area
Skin engine enhancements (themes, guide colors, skin functions, weather settings...)
Contact us
RSS
Top
Bottom