Rockbox Development > Feature Ideas
config per directory?
torne:
On some of the flash targets, accessing the flash brings the flash chip out of an automatic sleep mode which consumes less power, so it *can* shorten battery life: the difference is much smaller than a hard drive, of course, but it may still be measurable.
JdGordon:
why has noone mentioned that loading a cfg every (few) track change(s) is a very bad idea because just loading the .cfg is expensive?
There is no way to know which settings a cfg change and most cant be applied inidivudally so you not only need to check for the cfg, you also need to parse it (~200 settings in a massive table which needs to be scanned to figure out what a .cfg line means and how to store it), then we need to apply all settings which includes reloading fonts and themes (which can also actually mean stopping playback and restarting(!))
putting it mildly, this is a very stupid idea from an implementation point of view.
Now, a better solution to almost all the reasons for this has been posted already and I'll post another. Someone rework the quickscreen like has been menionted in one of the other threads to give you almost the same amount of control without wasting time with .cfg files.
pabouk:
I think no one supposed that per-directory cfg will contain all the possible options. As I can summarize from this thread users need to change just few parameters. I do not understand why most of the settings cannot be applied individually. Do you think that this is the case of the parameters mentioned in this thread? Of course reloading fonts and themes would be really bad if we want to change just EQ, crossfeed or automatic bookmarking.
Stopping and restarting playback does not matter. I think no-one will complain if there will be exception to gapless playback.
We probably do not need unlimited number of configurations so they can possibly be stored in a parsed form at a single location or maybe loaded into RAM from single cfg during Rockbox startup.
I can imagine that the implementation could be complicated but finally should the software follow easy implementation or usability?
I do not know about a better solution (in the sense of usability). All other solutions require manual intervention of a user.
saratoga:
--- Quote from: pabouk on September 15, 2010, 11:14:13 AM ---I can imagine that the implementation could be complicated but finally should the software follow easy implementation or usability?
--- End quote ---
To be perfectly clear, the only way this will be accepted is if you have a good implementation. Usability is not even a consideration until you have that. So if you frame this as a choice between one or the other, consider the idea rejected.
Anyway, since the only people actually discussing how this could be implemented seem to agree its both a bad idea and not worth implementing, is there any reason to leave this thread open? IMO we seem to agree that we're not going to have the buffering system handle config files, and the only remaining thing to discuss is improving stuff like the quickscreen or hotkeys. IMO that should probably go in its own thread.
Confuseling:
Personally, I see no need to lock the thread - it got somewhat heated at points, but has remained civil. Your prerogative.
Final suggestion then, and I'm not going to argue the point; you could limit it to top level directories (or even just literally audiobooks, music, and podcasts), presumably allowing you to load all configurations at boot with minimal interference with the present system.
This would meet some of the use cases, and provide a stepping stone to work from, while heavily limiting the problems. If the problems became tractable at a later date, you could loosen the limit.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version