>The problem is that a lot of code is needed to implement this >flexibility which results in that it takes more time to maintain it and >it definitely takes more time to test new releases. > Yes, I can understand that. Perhaps "Developer time" is also considered a "resource" in this regards.
>Some users also get scared of all the options and give up before they've tried. > I have never agreed with arguments that there should not be options because they confuse users. It's just a matter of good organisation/presentation. >As pippin says, keeping all this configuration in cache/memory also >makes it use a lot of resources. > My CustomBrowse prefs file is 52K - quite a lot, but compared against my current SBS process mem usage of 201,504K, it's still irrelevant! >Another problem is that the current solution is slow because in some >cases the SQL gets more complex than necessary. > >I'm pretty sure it would be possible to optimize the performance with >the current solution and probably also the resource usage. I'm just not >sure it's worth the trouble if many users decides to not use it because >there are too many scary configuration options. > Personally, I don't think people decide not to use it because there are scary configuration options. It mainly works straight after installation, and via templates, it's easy to choose pre-configured setups. It could even provide more pre-configured settings (eg. replicate standard browse menus, plus some frequently requested menus), and still provide the current options to change that default configuration. You could split CustomBrowse into two plugins - one for configuring CustomBrowse, and one for running the current configuration. Once a user has configured the browse menus appropriately, they can disable the configuration part (or only load that part on demand). >I would personally want a solution where the user only had to specify >the hierarchy, for example "conductor,work,movement" or >"decade,artist,album,track", and based on that perl code would make >sure to retrieve the information correctly. > I think that would be a nice additional feature for configuring some simple browse menus, but on its own that loses a lot of functionality, eg. the ability to create their own lists, eg. browse by artist first letter, browse by custom tag, etc. I think even having to enter a hierarchy (such as a comma-separated string), is too much for some users, which is why I think your current approach of providing common browse menus for selection works well. If there isn't one available, it can be configured by someone that is brave enough to create a new browse menu using a similar template, or even braver to create one from scratch or write custom sql, etc. i.e. there are levels of configurability that should cater for all types of user. >Another issue is that without a solution to the scanner hooks, the 7.6 >release with auto scanning enabled will be impossible to use together >with Custom Scan. > 7.6 is currently impossible to use without any plugins anyway. Auto scanning enabled or disabled, I can't get anywhere with it :-( >And Custom Browse without Custom Scan is pretty useless. > Not at all - I have many custom browse menus that don't use custom tags (or is there some other reason why custom scan is needed for custom browse to work?). eg. you can browse by rating, using Custom Browse + TrackStat without Custom Scan? >Hopefully Logitech prioritize to implement some third party API's where this >enhancement one of them. Hope is about as far as it goes at the moment I think. Logitech can't even prioritize to tell us what they are currently working on, let alone what they are planning to work on. There's no roadmap (although previous roadmaps haven't been useful, as they aren't followed). _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
