98
edits
Changes
Jump to navigation
Jump to search
Line 16:
Line 16: − + Line 33:
Line 33: + + + + + + + + + + + + − ''Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions.''+
Added scope and a screenshot
* Targeted release: N/A
* Targeted release: N/A
* Last updated: 06/29/2010
* Last updated: 06/29/2010
* Percentage of completion: 10%
* Percentage of completion: 5%
== Detailed Description ==
== Detailed Description ==
== Scope ==
== Scope ==
* Work needed for fvkbd
** While the fvkbd binary is good enough for initial prototyping, for tighter integration in the future, it may be useful to utilize the libfvkbd library and implement the keyboard as a part of the sugar-shell itself.
** The current version of fvkbd handles all non-primary layouts as "temporary" layouts, which mean that once a key is clicked, the keyboard state goes back to the primary layout. This makes it unusable for multiple keyboard layouts. I have [http://bugzilla.moblin.org/show_bug.cgi?id=10508 proposed a patch]. The maintainer suggests an alternate way to do this, and I think his idea makes sense (though there is no patch for it yet).
** The number of layouts for fvkbd is quite low, and it is not possible to do a 1:1 transition from XKB to fvkbd layouts. I have made an [http://dev.laptop.org/~sayamindu/sugar-vkbd-test/olpc-single-es.xml.gz experimental Spanish layout], along with a [http://dev.laptop.org/~sayamindu/sugar-vkbd-test/olpc-dual-bn.xml dual layout] with English and Bengali (it requires a patched fvkbd, and the patch can be obtained from the [http://dev.laptop.org/~sayamindu/sugar-vkbd-test/olpc-single-es.xml.gz bug] mentioned above).
* Work needed in Sugar
** It is still not clear on how to best integrate the keyboard into Sugar. The most easy and obvious approach is using a [http://dev.laptop.org/~sayamindu/sugar-vkbd-test/keyboard.py device icon] in the frame, but it would be useful to have the keyboard pop-out automatically when an editable widget has focus. See the discussion on GTK+ modules below.
** One major drawback of an on-screen keyboard is that in its current design, it blocks out a part of the Sugar UI. There's no immediate answer on how to handle this problem.
** Starting up the keyboard process is currently done in the prototypes using [http://dev.laptop.org/~sayamindu/sugar-vkbd-test/sugar-session sugar-session]. However, it may be useful to have this capability as a Sugar service, so that the keyboard can be invoked by activities as and when required.
* Work needed elsewhere
** GTK+ module to handle focus-in/out events
*** A GTK+ module which would automatically invoke/close the keyboard when the user focuses into/out of an editable widget would probably be a good addition.However, while standard GTK+ widgets such as GtkTextView, etc can be easily identified as being editable, widgets such as those used by Write (Abiword) and Browse would be difficult to detect. Moreover, for activities like Etoys and Scratch, which do not use GTK+ at all, one would need to use some other approach.
*** Code for a proof of concept GTK+ module which tries to detect focus-in events on common editable widgets can be [http://dev.laptop.org/~sayamindu/sugar-vkbd-test/on-screen.c downloaded]. Usage and compilation instructions are in the comments.
==UI Design==
==UI Design==
[[Image:Sugar-ES-Onscreen-KBD.png]]
== How To Test ==
== How To Test ==