Rockbox Development > Feature Ideas

Why is autorun disabled?

(1/2) > >>

grums:
A few weeks ago I made a build (based on 3.7.1) with a
#define AUTOROCK
line included, enabling me to run a plugin at startup.
Why isn't this brilliant feature enabled by default - it doesn't seem to hurt if you don't have a properly named plugin in place?

saratoga:
My guess is that its probably to save time on boot up checking to see if a file exists that 99% of people will never use.  Might be worth searching the IRC and SVN logs though to see if any other rationale is given.

gbl08ma:
Talking about boot up time savings, it's not specifically directed to this question but, why doesn't Rockbox check for the files in background, leaving users in the main menu and fully operational.

The menu would show up for a second or so, and then if the background code verified the existence of a plugin to be autorun, the plugin would be launched.

What I'm saying is kind of a concept, it doesn't have much technical basement behind it, but anyways I leave here the idea (as this is on the Feature Ideas section... it's on the right place).

torne:
The time at boot is virtually zero, even with dircache off. Several things at boot check for the existence of a single file.

It was discussed here: http://www.rockbox.org/irc/log-20100427
The conclusion was that it should probably become a setting similar to the backdrop/etc: i.e. rather than renaming a plugin you would just select the plugin from the menu, go into the context menu, and choose it to run on startup. If someone wrote a patch to do this, it would be much better than the current autorock feature.

JdGordon:
of course it is mostly irelevant.. really the only plugin you would want to start on boot is pictureflow, and you can already do that

Navigation

[0] Message Index

[#] Next page