How can I help Rockbox development ?

[Noxneo]

Hello, this topic is mostly for developers. I don't know if it should be posted here, but I didin't wan't to harass devs with MPs.

I have used Rockbox for quite a while know, and I would like to get more involved with it (being familiar with computing in general). I used iPod Linux (being a Linux user myself), but I found out Rockbox was better (IMO, of course ).

I can code in C fairly well (I know a bit about the SDL too, even I don't think this is of any utility for Rockbox), even though I know absolutely nothing of embedded software programming.

But I think the major thing I could help with is translation, being a native french speaker. I have done several translations from English to French in the Gnome French Translators Team, by the way.

So I just wanted to know if you needed me in any way, or not.

Thanks

[Febs]

Hi Noxneo-

Though I am not a developer, I can point you in the direction of a couple of Wiki pages that might get your started:

First Time Guide to Rockbox Development:  http://www.rockbox.org/twiki/bin/view/Main/DevelopmentGuide

Index of other wiki pages for developers:  http://www.rockbox.org/twiki/bin/view/Main/DocsIndex#For_Developers

Rockbox mailing lists (if you haven't already done so, you should subscribe to the developer's mailing list):
http://www.rockbox.org/mail/

I would also encourage you to visit the Rockbox IRC channel at #rockbox on freenode.net, as that is where most of the developer discussion occurs.

I hope this helps.

[Noxneo]

Thanks a lot

However, I didn't not find anything about translation. Does that mean that translation is done with, or not a priority ?

[Llorean]

One place to start could be with the localization. Take the French.lang file and compare it with the English.lang file, making sure all non-deprecated strings are translated in a way you feel is effective.

[Noxneo]

Last question, and I get to work  

Which program do you recommand to mess around with lng files ?

[Llorean]

Any text editor that won't change the line endings, preferably. For example *not* notepad. ConText is a friendly, freely available one if you don't have something like that.

Also, I can't remember if you want the .lang or .lng files honestly. One of the two should be plaintext, and that's what you want.

[RaeNye]

Here are some things you can do, in an approximately increasing order of difficulty:

Translate .lang files.

One place to start could be with the localization. Take the French.lang file and compare it with the English.lang file, making sure all non-deprecated strings are translated in a way you feel is effective.

Create plausible settings.
Equalizer presets, FM radio presets, config files, ...
If they're good, they might get shipped with RB.

Design fonts/WPS/themes.
Very similar to the previous point, but requires artistic talent as well .
See all about it in the wiki.
See also examples of other peoples' WPS on the wiki.

Help writing the manual.
When people come to the forum/IRC and ask newbie questions, you can't tell them to RTFM without a comprehensive manual, can you?
RB manual is kept in CVS along with the code, so you can check it out and improve it. Flyspray has a category for submitting manual related bug reports and patches.
Basic TeX knowledge is required.

Test bug reports from flyspray and report their status on your target.
If you find they need a specific setting to happen, post the setting (or your entire config file).
Most bug reports don't even require you to compile a custom build, however you could compile a simulator/logf build and test there as well.
Examples: FS#5683 FS#5713 FS#5796
Don't forget to comment on the tracker with your findings.

Test patches from flyspray and report their status on your target.
If the patch claims to fix a bug, verify it's gone after patching.
If the patch claims to add a requested functionality, check that it actually works.
If the patch optimizes code, report how well it does (e.g., before: 18 FPS, after: 25 FPS)
If the patch doesn't apply cleanly, sync it if you can and report it otherwise.

Testing patches usually require you to compile a custom build, but no programming knowledge is necessary.
Examples: FS#1961 FS#2235 FS#2893 FS#5641

Fulfill feature requests from flyspray.
Browse flyspray for a feature that you would like to see in RB (most probably you already have one in mind) and implement it.
Try to pick something that is not too narrow (e.g., I want that REC button would toggle this-and-that setting on/off) because this has little chance to get committed.

If you're writing a plugin/codec, it's best to find a open-source implementation and adapt it to RB. Usually the main porting issues are input, output, OS calls and floating-point support.
You don't really have to know embedded programming for that, but the state of mind is quite different than PC programming.

If you're adding a HW-specific feature, read the relevant specs sheet (if available) or reverse engineer the OF for the needed functionality. This kind of development is usually harder, since you have to test it on the DAP itself and it's easier to crash it when doing low-level stuff

Writing patches requires programming, obviously.
Examples: FS#4755 FS#5192 FS#5792 FS#5923

R.
-----------------------------

A specific note to Noxeno -
Maybe try to work a bit on improving the UI simulator, it uses SDL and needs some work.
Possible improvements - separate remote LCD window and main LCD window, add remote background, add remote keymaps, make remote detachable/replaceable (there're 3 types of remotes for H1xx/H3xx).
References: FS#4905 FS#5010 FS#5875

[bk]

Also, if you're interested in profiling code there's lots of things that could use optimization. All the codecs (libfaad and perhaps Tremor in particular), plugins such as rockboy and mpegplayer, the display libs, etc.