Thank You for your continued support and contributions!
There are as many proposed designs for a restructure as there are people using their players regularlyAllowing total customisation would mean it's far more difficult to guide users to the correct settings to address related issuesAllowing total customisation looks like it would be non-trivial to implement from a technical point of viewThere are issues concerning how a user would define "their" menu structure - PC utility? config file? - although with rose-tinted-precognitive spectacles, you could imagine a situation similar to sharing WPS files where structures tailored towards common use cases are shared.
Quote from: seani on November 09, 2009, 07:25:14 AMThere are as many proposed designs for a restructure as there are people using their players regularlyAllowing total customisation would mean it's far more difficult to guide users to the correct settings to address related issuesAllowing total customisation looks like it would be non-trivial to implement from a technical point of viewThere are issues concerning how a user would define "their" menu structure - PC utility? config file? - although with rose-tinted-precognitive spectacles, you could imagine a situation similar to sharing WPS files where structures tailored towards common use cases are shared.point 1 is correct... 2 is a cop out answer... new users will get the default layout, support can always say "revert any menu changes or we wont help you". 3 is outright wrong... every menu item in the current menus is uniquely identified already (by its english language string), or for the case of settings, its cfg setting name. To build a menu tree is trivial (well, easy if you know what you are doing... 4) building a parser for the text file would be harder than building the tree from the menus... but we already have at least 4 (maybe more) text parsers in the core.. so one more wont hurt (tagnavi.config, viewers.config, skins, .cfg files are the ones i immediately think of).Now, that said, what (I think) you are proposing is harder to implement because while you can dynamically hide menu items right now, you cant decide at runtime which to check for, you have to do it at compile time, which means you enable the check for everything, which means bloating the core with settings, and slowing down the menus because *every* redraw every item needs to be checked.So, in my not so humble opinion, the only way worth the effort is to allow full menu customisation and bugger support.
Page created in 0.118 seconds with 20 queries.