We asked our 3 trainees to do some little projects to make sure that we ironed out any problems in their C knowledge before moving on to C++, to get them familiar with autotools, and generally to have code to talk to each other about. I forced them to make actual tarball releases, so they can also complete features as if there were real users, instead of just hacking without focus. These are the modest results. Click on the links to see the descriptions and screenshots on their blogs.
Jon Nordby’s massifg: To show graphs from valgrind massif output. So far it only shows the simple graphs, though using the Cairo drawing API makes printing to PDF easy, so it’s already useful. I want Jon to do the detailed graphs too, but I’ve asked him to look for a proper Graph API first, because it’s tedious to do it all with just Cairo. Hopefully without acquiring awkward dependencies. He’d welcome advice.
Chris Kühl’s GMemory: One of those games that lets you turn over tiles for a moment and try to find matching tiles. It uses clutter and could probably be a candidate for the gnome-games package soon.
Patricia Santana Cruz’s GHangTux: A hangman word-guess game in which Tux the penguin loses his accessories rather than his life.
(The Gs in the names were their idea.)
I think they have all learned lots from the exercise and are ready for the next stage.
I am doing part of the project “Persian Linux” and I would be grateful if you could answer my question:
if me as a developer write a piece of code for GNome or KDE, what steps does this code should pass in the repository of these two sets so that it gets public usages, in the next future updates and productions?
I apreciate you if you could send the answer to my email.
Harir,
If it’s an improvement to an existing module, then you should talk to the module’s maintainers.
If it’s a new module, then you can propose it: http://live.gnome.org/ReleasePlanning/ModuleProposing