Rockbox General > Rockbox General Discussion

How can I help Rockbox development ?

<< < (2/2)

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.

--- Quote from: 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.
--- End quote ---

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 ;D.
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.

Navigation

[0] Message Index

[*] Previous page