Tux4Kids Tasks for Google Code-In 2011

For T4K Mentors, Admins, and Team Members:

The format for Google Code-In has changed significantly for 2011. Mainly, the lists of task are much more structured. Each project is required to post at least five tasks of varying difficulty in each of the five categories listed below. As you will see, some of these are more readily applied to our software than others. Still, I think we should be able to come up with tasks for all of these categories, even if some turn out to be things that may not be chosen by any student.

On 16 Dec 2011, we will have the opportunity to add more tasks to replace the ones that have been completed.

Please enter tasks in plain text into the outline below, which has been copied from the instructions page for GCI admins and mentors and lightly formatted.

Task List:

Note: all tuxmath and tuxtype code tasks should be done using a clone of the respective git repositories:

TuxMath: git://git.debian.org/git/tux4kids/tuxmath.git

TuxType: git://git.debian.org/git/tux4kids/tuxtype.git

For TuxPaint, see this page: http://www.tuxpaint.org/download/source/cvs/

Completed code tasks are to be submitted as patches (read about GNU diff and patch utilities).

• Code: Tasks related to writing or refactoring code (Keep in mind the young age and likely inexperience of the student: the more independent thought and breadth of technical knowledge the task requires, the harder you should consider it. Try to break a task into multiple smaller tasks: if you can't - that's a hard task.)

1. (easy) Some Tux Paint magic tools raises warnings about unused parameters. Task per magic tool: Remove those warnings, see how the other magic tools handles this.
2. (medium) Currently TuxMath displays a fixed logo during loading. Under certain circumstances, loading can take a while. For this task, create and add an animated logo to the startup screen so the user knows the program is still running.
3. (medium) The main TuxMath comet game is currently hard-coded to a frame rate of only 15 FPS. Change it to 60 FPS. This will require adaptation of all the various on-screen animation routines. (aviraldg - This will cause the game to become unplayable on slower computers; the next task is a far better alternative.)
4. (hard) Instead of merely increasing the hard-coded frame rate in the comet game, change to a time-based motion system that is also independent of screen resolution. (mentor: aviraldg, if possible)
5. (hard) Decouple TuxMath's (2 tasks - one for Comet Game, one for Factoroids) "rendering" system and simulation system. As mentioned above the game currently runs at 15 FPS, for both simulation and rendering. If the task above is completed, this one must also be completed for there to be any advantage from the change at all.
6. (hard) The Windows build of tuxtype has a bug - if the player hits the "Windows" key while playing the fish game fullscreen, tuxtype is minimized but the mouse remains trapped at (0,0), making it hard for the user to do anything. Find this bug and fix it. Hint: TuxMath does not have this problem. This is being labeled "hard" in part because it is significantly more work to get a Windows build set up than a native linux build.
7. (hard) TuxMath's question lists are created in mathcards.c/h. However, as currently implemented there can only be a single instance of mathcards running, which makes it impossible for the server to handle multiple games in the LAN version. For this task, make mathcards "thread-safe" so that multiple instances can safely run. Hint - each instance should have all its variables encapsulated within a struct, and the mathcards functions used by the game will need another argument to identify the correct mathcards instance. (Perhaps this task is "really hard"). [mentor: aviraldg, if possible :)]
8. (hard) Write a gimp plugin that is able to import/export xcf format to/from a tuxpaint made png with embedded metadata. See do_png_embed_data function in tuxpaint.c for details and documentation. See the task listed in research for specs that have to meet the plugin. Preferably it should be in a language script (python, scheme...) rather than C as it would be more easy redistributable. Before this task will be assigned, the research task about the specs this plugin should have needs to be completed. Ask in the tuxpaint devel mail list if you have doubts about it.

• Documentation: Tasks related to creating/editing documents (consider length of file)

1. (medium) Review the existing plain-text documentation for TuxMath (e.g. doc/README, doc/INSTALL, etc.) and make sure it is up-to-date. Look for references to old version numbers, etc. See if any new features have not yet been documented.
2. (medium) Review and update the existing plain-text documentation for Tux Typing (e.g. doc/README, doc/INSTALL, etc.).
3. (medium) Create an attractive HTML user manual for TuxMath, describing how to install and run the program. Include screenshots or other graphics. You can base this on doc/README et. al. in the source tree. You should use Sphinx for this task.
4. (medium) Create a similar manual for Tux Typing, using Sphinx for this task.
5. (hard) Create a TuxMath manual as above, but that is designed to be internationalized using GNU gettext.
6. (hard) Internationalization-friendly manual for Tux Typing.

• Outreach: Tasks related to community management and outreach/marketing (Videos = easy, talk for an audience = medium, written promo or web page = easy)

1. (easy) Create a YouTube video displaying the "Factoroids" activity from the most recent stable version of TuxMath.
2. (easy) Create a YouTube video showing how can you hide messages in a tuxpaint drawing using the label tool.
3. (medium) Give a presentation about the Tux4Kids apps at a local elementary school. This could be at a parents' association meeting or similar. This should include both a talk and a demonstration of the programs themselves. Explain how to get the software, and make it clear that the programs are completely free and non-commercial - we aren't trying to sell them anything.
4. (medium) Create a YouTube video displaying the LAN competition mode of TuxMath, with at least four players competing on separate computers. Note that this will most likely require installing TuxMath in a school computer lab ;)
5. (hard) Organize an elementary school math tournament using the LAN competition mode of TuxMath. Make note of any problems encountered deploying or running the software, or any difficulties experienced by the children. Document the tournament with a well-written web page or blog post (anything you write for the web should be reviewed by a teacher or other supervisor at the school to avoid improper posting of identifying information). Photographs (if allowed) are a definite plus.

• Quality Assurance: Tasks related to testing and ensuring code is of high quality (varies by task)

1. (easy) Look through all of the source and header files in TuxMath and confirm that all files have appropriate copyright notices. Add a FIXME comment to any file that appears to be lacking appropriate notices.
2. (easy) Confirm that all files in Tux Typing have copyright notices.
3. (easy) Confirm that all files in Tux Paint have copyright notices.
4. (hard) C programs are prone to crashes from errors in the use of pointers and arrays. Many of these errors can be detected using tools such as Valgrind. For this task, analyze tuxmath with Valgrind. For each issue identified, either fix it (if the fix is straightforward) or place a FIXME comment in the code describing the error or warning. Note: Be wary of the Valgrind tasks, because SDL in itself (a library that TuxMath uses) is not perfect and has memory leaks in several places.
5. (hard) Run Valgrind on TuxType and address any issues, as above.
6. (hard) Run Valgrind on TuxPaint and address any issues, as above.
7. (hard) Some of the code in TuxMath isn't very well organized. This means that several important files related to the game are essentially monolithic pieces of code. Break them up into smaller parts and make them more generic in nature. For example, in the Factoroids game, the logic for the ship and the asteroids could be split out into separate files and could be treated exactly the same in factoroids.c by using an annotated struct (for each). This would greatly simplify the code.

• Research: Tasks related to studying a problem and recommending solutions

1. (easy) There are too many magic tools in Tux Paint. Classify the Tux Paint magic tools in categories of use. (painting, filling...) and propose how they could be splitted in several menus.
2. (medium) Research and write a document on what constitutes a "fun" user interface (especially designed for kids). The current interface feels "rigid" and isn't all that fun to use IMHO. For inspiration try looking up some of the design ideas used in Android. Highly subjective, but: list overscroll is fun, transitions are fun, bouncy stuff is fun (have a look at the effect used to animate boxes in the menu of Cut The Rope) etc.
3. (medium) Research on the elements of TuxMath that actual kids particularly enjoy and write a short essay on how you think those elements could be enhanced.
4. medium) Define the behavior that should have a gimp plugin that imports/exports from/to the new format tuxpaint uses(png with embedded data in custom chunks) and xcf. See do_png_embed_data function in tuxpaint.c for details and documentation. Ask in the tuxpaint devel mail list if you have doubts about it. Write a document with all use cases, the suggested behavior and reasone it. If you see various valid alternatives, present them and reasone what do you think is the best.
5. (hard) Design and conduct a study comparing TuxMath to paper flashcards for learning math facts. This will need to be done with the help of an elementary school teacher at the proper grade level. Divide the kids into a "TuxMath group", and a "flashcards group". Have them use one or the other for a few days. Test them before and after, and see which group improves more. Make note of what the students find good or bad about TuxMath. Write up your experience. If possible, post something online about it. Make sure you have permission from the school and parents for everything you do, and get all online postings reviewed by a teacher beforehand.
6. (hard) Design and conduct a study to see if Tux Typing helps kids learn lists of spelling or vocabulary words. The study should have both a Tux Typing group and a control group. Observe the use of Tux Typing, and include any positive or negative observations in your report. Get permission from the teacher and parents.

• Training: Tasks related to helping others learn more (online training page for single feature or command = easy, online training page for a section/group of tools or commands 1-10 = medium, more or complete set = hard)

1. (easy) There are quite a few YouTube videos about our programs. Go through them and find which ones provide the best instruction on how to use the software. Provide a list of the best ones for us to include on our web site.
2. (medium) Create a YouTube video tutorial that systematically and logically illustrates all of the features of TuxMath. The tutorial should also show how to download and install the program. As this is "training" rather than simply "outreach and promotion", it is important that it be quite comprehensive. The plan will be to have a link to this video on the Tux4Kids web site.
3. (medium) Comprehensive video tutorial on Tux Typing, as above.
4. (medium) Comprehensive video tutorial on Tux Paint, as above.
5. (hard) Install the Tux4Kids apps on multiple computers in a school computer lab, library, community center, church youth area, or similar public setting. Teach whoever runs the lab how to use the programs. Make sure you have appropriate permission before you install any software! The supervisor of the lab will need to send an email confirming what has been done.

• Translation: Tasks related to localization (Marketing pages (any) = easy, code documentation by feature/ command = med to hard based on length /# of pages/going from a language that uses Roman characters to a different character set or vice versa) (Note to orgs: Be sure to have someone that can check the efficacy of the translation before approving it).

1. (easy) Update the Catalan translation for Tux Typing (file = po/ca.po in tuxtype source tree)
2. (easy) (and fun) Translate TuxMath to Pig Latin.
3. (medium) Update the Catalan translation of the Tux Paint website (file to translate = ftp://ftp.billsgames.com/unix/x/tuxpaint/website/po/ca_ES.po)
4. (medium) Create a Catalan translation for Tux Math (template file = po/tuxmath.pot in tuxmath source tree)
5. (hard) Translate the website of Tux Paint to Spanish (file to translate = ftp://ftp.billsgames.com/unix/x/tuxpaint/website/po/tuxpaint-website.pot)
6. (hard) Update the hindi translation of Tux Paint (file = ftp://ftp.billsgames.com/unix/x/tuxpaint/website/po/hi_IN.po)

• User Interface: Tasks related to user experience research or user interface design and interaction (time- based measurement)

1. Add a new onscreen keyboard layout to Tux Paint. to add greek, arabic, russian, hindi... keyboard layouts.(easy if you have the keyboard configured to the targeted layout and have the xmodmap command available.)
2. (medium) The graphics in Tux Math and Tux Typing are of varying quality. Decide which images look too amateurish to you, and create more professional-looking replacements. Ideally, the images should be in Scalable Vector Graphics (SVG) format. These images can be created with the proprietary Adobe Illustrator program, or the Free/Open Source program "Inkscape" (http://inkscape.org). This task may be done more than once. (aviraldg: Before the program actually starts, I think we should actually clarify about exactly which graphics need to be redone.)
3. (hard) Redesign TuxMath's menu interface in accordance with the aforementioned "fun UI research" document. This includes providing new graphics for any changes made (including "source" files).
4. (hard) Similarly, review the menu system for Tux Typing and propose improvements in organization of menus, graphics, or responses to user events.
5. (hard) Make changes in the UI code in accordance with the above mentioned task.