Re: Constuctive suggestion/Attracting more users/Install theme with first launch

[thenrik]

Hi:

  I've been reading the forums and have noticed a number of users so mystified by the install/setup process that they revert back to the original firmware of their player.

  Upon first launch the file explorer is set to a six point, tiny, font with a screen fade of two or three seconds. It appears to new users to have an unreadable  interface that crashes immediately.

  Through trial and error and reading the manual, I first changed fonts and then loaded a theme. I couldn't tell you which one it is of the three choices but it has a light yellow background, shows the song and id3 tag info, the bitrate and shows the next track at the bottom of the screen.

  The theme stopped the two second autofade and made the Rockbox interface understandable.

  I would say loading a theme with a readable font and stopping autofade would greatly increase the number of users or at least stop folks from bailing in the first ten minutes.

My two cents,

Tom

[bluebrother]

You should really keep in mind that rockbox runs on a couple of players. While a 6 point font is tiny on an ipod video it is a good choice on the iriver h100 if you're not too much into big fonts, and on the archos recorder it is a good choice. So, while there could be better defaults for some settings, the main problem is that it's different for each device.

I was thinking about the possibility to ship a couple of default configurations. Due to the lack of time I haven't been looking further into this. But if someone wants to use Rockbox he should have the time at least reading the first parts of the manual. It's all explained there.

Feel free to start building up a list of good default configurations ...

(Btw, the fadeout time shouldn't be affected by a theme. If it does, it either is a complete configuration file or the theme file is broken)

[Llorean]

Well, just *today* it became much easier to have different defaults by target since config can now be loaded from an initial file rather than using hardcoded defaults, by simpling shipping different targets with a different default config file in .rockbox

[linuxstb]

We don't want to ship default config.cfg files - that will overwrite the user's current settings...

Instead, the default theme-related settings need to be made target-specific.

But I agree that it's a good thing to do all we can to improve the first impression users get of Rockbox.

[bluebrother]

My idea is (and was) not to ship a default config.cfg but instead put one (or a couple of) configuration files fitting best for most users somewhere. Maybe simply add a good configuration in the root folder and call it "configuration.cfg". Users trying to "open" the magic "rockbox folder" (which we all know isn't a folder but restarts Rockbox) would then find a "configuration" folder and loading that could set useful defaults. I think there is a chance such users would actually "run" the configuration, and that could set filetypes to "music" et cetera.

I'm pretty sure this could help new unexperienced users.

[tucoz]

Maybe simply add a good configuration in the root folder and call it "configuration.cfg".

We could also call it "run_1st.cfg", "try_me.cfg" or something like that. Or, we could play a little game and call it "warning_dont_touch.cfg"

[Spug]

Speaking of the "magic Rockbox folder" - is there a good reason why it's not set to "hidden" by default? Is it there so users can reset Rockbox easily?

[Bagder]

Speaking of the "magic Rockbox folder" - is there a good reason why it's not set to "hidden" by default? Is it there so users can reset Rockbox easily?

It is hidden on all *nix-like systems (since it starts with a dot) and on the rest it can't be set hidden since then the hidden bit is a feature of the filesystem and not something we can ship in a zip file.

[pabouk]

We don't want to ship default config.cfg files - that will overwrite the user's current settings...

The current code does not really support default configuration in a file. I think that Rockbox should check for the presence of config.cfg and only if the file is not found it should load default.cfg which could be easily shipped with the firmware.

[Llorean]

My thought was that there could be a default.cfg and a current.cfg. If current.cfg does not exist, default is used, but user's settings are stored in current.cfg instead. So, a clean install gets default.cfg, but user settings are never overwritten because current.cfg isn't included.

Then you can easily package target-specific settings, that way.

[saratoga]

My thought was that there could be a default.cfg and a current.cfg. If current.cfg does not exist, default is used, but user's settings are stored in current.cfg instead. So, a clean install gets default.cfg, but user settings are never overwritten because current.cfg isn't included.

Then you can easily package target-specific settings, that way.

This sounds like a good solution to me.  

[Flid]

How would this handle multiple user specific config files (ie. At_Work.cfg, Car_Mode.cfg, Jogging.cfg etc)?

Could rockbox be coded to always write the user chosen .cfg settings to the current.cfg on shutdown? If so, that could work.

[Llorean]

Rockbox currently writes a config on shutdown. That's what current.cfg would be.

[NicolasP]

I reckon it already exists and it's called config.cfg.

[Spug]

Speaking of the "magic Rockbox folder" - is there a good reason why it's not set to "hidden" by default? Is it there so users can reset Rockbox easily?

It is hidden on all *nix-like systems (since it starts with a dot) and on the rest it can't be set hidden since then the hidden bit is a feature of the filesystem and not something we can ship in a zip file.

It sounds like you're talking about the /.rockbox folder? I, and bluebrother, I think (since he said "which we all know isn't a folder but restarts Rockbox"), meant the /rockbox.target file ("rockbox.iriver", for example). Many users don't realize what the "rockbox.target" file is, and I was just wondering the reason why it's not called ".rockbox.target" instead (with a preceding dot) so that it's hidden in regular view. Is it just meant to be a convenient shorthand to restart Rockbox?