I am of the opinion that we should make the keyboard definition format for the SOK a superset of the GOK format.  This way existing keyboard files could be used, but there would be more options for those that would like to embellish their keyboard with things such as color shaded keys.  The only detriment of this would be that the GOK would be likely unable to use SOK files, and I don't really see that as a bad thing. <div>On 5/9/06, Henrik Nilsen Omma <<a href="mailto:henrik@ubuntu.com">henrik@ubuntu.com</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hi everyone, The application deadline for SoC students is nearing an end (though it has been extended by Google by a day or so) and I'm pleased to see a good number of applications for 2 of the 3 AT projects (nobody applied for the config panel, which can understandably seem boring). I won't go so far as to post all the applications here ;) but I'll post some more detailed thougths and invite discussion on the planned features and roadmaps (yes, this is in part me being lazy and not wanting to have 12 identical email conversations fleshing out spec details -- but I also think that an open process works better). I've copied in the SOK applicants on Bcc. Feel free to jump in with comments and ideas or just hang back and read the suggestions. To sign up: <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility">https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility</a> The advantage in this open approach is that there are many people reading this list who know a great deal about accessibility and others who know much about ubuntu and development. The spec ideas still need a fair bit of fleshing out and input from experienced people. The sooner we start that process the better positioned we will be when it is time to start coding. I'll be doing the same with the XGL-magnifier later. The Simple On-screen Keyboard -------------------------------------------------- Let's start by dividing this up into milestones: M0: Select The language and libraries we will use   * I'm leaning towards python with pyGTK, but I'd like to hear other suggestions with reasons (where is python's xlib support, do we need it, can we use C for some aspects?).   * I want to look at rendering the keys directly with Cairo instead of using a widget toolkit. That will give us more flexibility in the display and make porting to other platforms easier (or?).   * Make sure these have bindings we need, esp. to AT-SPI   * Decide on keyboard definition format. Can the existing GOK format be used or do we need to extend it with additional features (regarding key placement, colour, etc.)? M1: Proof of concept keyboard   * Make a 3-letter ABC keyboard that can pass keystrokes to the active application   * Should be able to be always-on-top without being active   * Keys rendered in Cairo (if we go that way)   * All settings are hard coded M2: A full QWERTY keyboard read from a file   * Read a key layout from an XML file   * Support for modifier keys such (Shift, Ctrl, Alt), probably without using Sticky Keys M3: General configuration handling   * Any configurations that that the user might want to make should be sepparated out from the code and read from a file   * The scheme used should be compatible with the Common AT config approach M4: Plug-in framework   * The core idea of SOK is to keep it lean and simple, with extra features added as plug-ins.   * Possible plug-ins might include: Word prediction, switch activation support, X-10 home automation support, ... M5: Non-latin and Tablet PC support testing   * The keyboard should be unicode from the ground up, so this should just work, but needs testing Optional features: I list these here partly as a braindump area for new ideas, but also to draw a clear line. These features will not be part of the initial implementation (to keep it simple) and may only ever be implemented as plug-ins. * Transparency and animation - these are cool and potentially useful things, but clearly non-core * Scriptability - Orca has shown us the advantage of adapting the AT tools to different applications. That may well have benefits for SOK as well. * Word prediction - very useful but not everyone needs it. Should be implemented as a plug-in or separate utility. Some will want prediction without an on-screen keyboard. * Graphical layout generator - Many will appreciate the ability to make their own layouts easily. * Configuration GUI - Should be seen in context with other AT apps, ideally as part of the common config panel (still just in planning) ----- Also, while I'm writing this, let me clear up a common misconception that came up in the applications: The main focus of this project is enhanced accessibility for disabled users. I mentioned tablet PC and multi-language input because I think it is strategically wise to factor in these use cases. If we make a working on-screen keyboard that can also be used in other ways we will get more testing and development. And if we don't then alternatives will eventually appear anyway. When one of the big PC makers decides they want to push tablet PCs for Linux they could either use our solution and help improve it or build their own non-AT version, which would be a small tragedy. After we get some feedback on this and nail down some ideas we should flesh out the spec in the wiki: <a href="https://wiki.ubuntu.com/Accessibility/Specs/SOK">https://wiki.ubuntu.com/Accessibility/Specs/SOK </a> - Henrik </blockquote></div>