------------------------------------------------------------------------- THINGS TO DO for GNU Typist See our latest TODO file on http://savannah.gnu.org/cgi-bin/viewcvs/~checkout~/gtypist/gtypist/TODO ! ------------------------------------------------------------------------- If you are interested in helping for some of the below items, we will be glad to have you in the development team! You can contact us by writing to bug-gtypist@gnu.org. Your suggestions are welcome too! SHORT TERM * In the older courses converted to use menus introduced in 2.7, banners sometimes don't change when you return to upper-level menus from lower-level ones, because corresponding B command does not occur in the right place (with respect to current syntax). For example, try to select lesson Q1, immediately press ESCAPE, and see that banner is still "Lesson Q1". This can be fixed manually, but it's perhaps better to wait until a new structurized syntax will come along with smart conversion utility. * Show correct line numbers when nonexistent label was hit in the M command. * I'd like an option that only enabled wordwrapping. The -w option does enable wordwrapping, but it also changes how paragraph breaks and spaces after periods are handled, which I don't want. Requested by Adam Olsen * Make `typefortune' available in /bin? * Support UTF-8, as today 1) charsets of the file and terminal must be the same; 2) they have to have no wide characters This already impacts users (reported by Jeff Nelson ) * Make sure that all source files come with a suitable copyright statement (may be different with lessons?) * Make FSF Europe the co-owner of the copy rights, to have a much clearer and cleaner situation. * Make contributors sign a paper accepting the terms of the GPL, according to GNU standards. * Implement a `word processor' option to make GNU Typist accept [SPACE] instead of [RETURN] for new lines. (Suggested by gherald@myway.com) * Make sure that the numpad's [ENTER] key is accepted in numpad lessons. (Reported by gherald@myway.com) * Fix ktouch2typ.pl script issues with the latest files from KTouch. * Update all the kt* lesson files from the latest version of KTouch. * Another idea is to generate our lessons files directly in our format from spelling dictionaries, as they do in KTouch. * Reuse lessons from dvorak7min and possibly other typing tutors. * Put all the program sources in the src/ directory * Replace 'getopt' by 'GNU gengetopt' * Improve the French translation of "lesson file", which includes both Drills (translated by "Exercice") and Speed tests ("Tests de vitesse"). * Standardize lesson file names, using standards for languages and keyboard types. * Make a separate package for lessons, so that lessons compatible with a given gtypist version can be released without having to release the tool again. This is already done by other packages: gimp plug-ins or TeTeX fonts are released separately. This is definitely need for this tool, for which tutorial files are at least as valuable as the raw program itself. * Provide a variant of the `n.typ' calculator keypad lesson, in which the `.' character is replaced by `,'. Useful for some european keyboards. * Improve the interface by adding 2 interfaces: * Graphical interface (Probably GTK) The benefits we can expect from a GTK interface are: - Much attractive than the `ncurses' interface. - Not using `ncurses' should avoid problems supporting different terminal types. - We could have a graphical control panel, to change settings that are so far only available in the command line (keyboard type, silent mode...) - Easy access to help and manual - Could still be compiled on Win32 on which GTK has been ported. * Audio interface Could use a system like Speech Dispatcher to read the lessons for visually impaired people or people living in very dense fog. We could also support audio typing exercises. Users would type from a text read by a speaker. Several audio files would be need, according to the language and the targeted typing speeded. That would be useful for people like secretaries and journalists. All this could be implemented in a clean way by implementing an event based mechanism. The core application could send interface messages to a generic interface manager, which could according to user settings, ask the graphical, text or audio interface to send it to the user. Specifications are on going. MEDIUM TERM * Add configuration file support. Should be every useful, in particular for teachers! * Improve the documentation of course files * Broaden our lesson database: - Create new lessons for other languages and keyboard types. - Translate lessons in other languages (for languages that share the same keyboard, you can reuse instructions and drills) - We can also look for teachers who are ready to contribute lessons or let us reuse theirs... - Reuse lessons from old typing teaching books which copyrights have expired (how much time does it take?). * Better typing statistics. Speed and accuracy for individual keys, and individual fingers. This helps to indicate where extra practice may be useful to the user (see Jtypist which displays this as graphical bars, using color to indicate areas that need work). A measure of typing rhythm would also be useful. LONG TERM * While typing, graphically show the finger that is supposed to be used. * Read lessons in the file formats of other free typing tutors (such as Jtypist). * Emulate other keyboard types. For example, Jtypist can pretend that you have a French, German, or Dvorak keyboard on the system even if you don't. It will translate keypresses between keyboard types before checking them for correctness, and registering timings. This work requires that the program should have keyboard layout maps available to it, and arises as a result of maintaining typing statistics by key and by finger (the program needs to know what key is operated by which finger).