GNOME Bugzilla – Bug 613229
Json to describe keyboard layouts
Last modified: 2010-06-10 15:55:42 UTC
Created attachment 156441 [details] [review] Creates keyboard from json file Hi, I think that the current implementation of how the keyboard layouts are configured is limited and should be flexible. It is configured using Python files and it doesn't allow, for example, to set a button/key label different than value to input. Also, Python files are not the best choice if non-technical people need to write new keyboard layouts, like designers for example. I have implemented a new way of describing a keyboard layout using json because of its flexibility and readability. So far, it allows: * Set the value to be inputted using a single char or any key name defined in GdkKeySyms: http://www.google.com/codesearch/p?hl=en#Zs4iv5zpNi4/trunk/gtk%2B-2.14.7/gdk/gdkkeysyms.h&q=gdk%20key%20sym&sa=N&cd=8&ct=rc This allows dead keys to be inputted, direction keys, etc. * Set a label which also allows markup. This allows to set a different label than the value that is to be inputted. If no label is specified, it will use the value for it. * Set a key's width. The widths are relative values, 1 means one key width, 3 means 3 a keys width. Defaults to 1. * Use specified key types, there are 4 types: normal, layout_switcher, preferences, mask and mask. The default is normal. ** The layout_switcher type will change the keyboard's sublayout to the one specified by the value attribute. The value should be a name of one of the layouts specified in the json file. So if I write a layout named "uppercase", I should put "uppercase" as the value in the layout_switcher and the generated button will switch to it when pressed. ** The mask type buttons will make the respective mask, pointed by the value, sticky. So a value of "control" will make the mask CONTROL sticky, pressing the button twice removes the mask. ** Dummy keys exist as spacers. If a row of keys has one less key than the above, for aesthetic purposes, one can add a dummy key for it to be aligned with the above row's width. Since these also have widths, one can add 0.5 width dummy keys to the beginning and the end of the row as an alternative to the example above. If a row has less keys than the then maximum number of keys in a row, it will be horizontally centered. I'm attaching two patches, one with the implementation and another with a QWERTY layout. Please note my patch gets the keyboard json file from the GConf key /apps/caribou/osk/layout (that should be now qwerty.json) but haven't implemented methods such as a listener to that key, etc. That should be done outside this patch anyway. I hope you integrate this. Cheers,
Created attachment 156442 [details] [review] QWERTY Json file Here is the promised QWERTY layout file.
Ooops, I messed up here: "Use specified key types, there are 4 types: normal, layout_switcher, preferences, mask and mask" It should be: "[...] 5 types: normal, layout_switcher, preferences, mask and dummy"
Hi Joaquim, The larger space button is good. I'm not convinced that the josn keyboard layout is a better solution than what I've already put in place. Let me study your patch a bit to see if it makes sense though. I'm also not convinced that using an 'offset key' layout like a hardware keyboard is the right approach. This might create problems for switch users using row/column scanning. This is a case where user testing will tell us what to do. I'll try to check this out some time next week when I'm at CSUN - sorry, I don't have the time right now.
Hi Ben, (In reply to comment #3) > Hi Joaquim, > > The larger space button is good. Cool. > > I'm not convinced that the josn keyboard layout is a better solution than what > I've already put in place. Let me study your patch a bit to see if it makes > sense though. What do you mean? How is a keyboard layout described using Python tuples a better solution than an abstracted and flexible one such as the implementation in json I did? I assume that designers and usability experts may want to design themselves keyboards' layouts and I find json a much more suitable format for this purpose. We could even discuss eventual security problems of importing Python files that way, should them (layouts) be provided by people outside the project. > > I'm also not convinced that using an 'offset key' layout like a hardware > keyboard is the right approach. This might create problems for switch users > using row/column scanning. This is a case where user testing will tell us what > to do. What does an 'offset key' mean? The layout I proposed was obviously just to show the flexibility that Caribou would then allow. You can for sure put up a "square-like" keyboard layout or anything that might fit better a type of user. Also, if one day Caribou is used in a mobile platform, a physical-like keyboard like the one I attached could be used. > > I'll try to check this out some time next week when I'm at CSUN - sorry, I > don't have the time right now. Sure, I understand, please consider these changes as they make Caribou much more flexible. Cheers,
With respect to the *general* question of using JSON for specifying keyboard layouts: I think JSON is a very good approach. JSON is a standard, text-based, general (abstract) way to transmit objects and their properties. (For reference: see http://json.org/). It's finding its way into various and unexpected places. Numerous languages have some form a JSON parser, including python (http://docs.python.org/library/json.html). As for the specific keyboard layout that Joaquim has proposed, I have no opinion, just questions. Does it follow Caribou's current keyboard layout design (Is that design documented)? That is, is it functionally equivalent? If so, my inclination would be to replace the python tuple technique with JSON.
Hi. I like the level of detail we would get with the JSON format you propose. One issue that I see is that the python json module is only bundled python in 2.6, while the excepted external dependency[1] is python 2.5.2. I see 3 options: i. Ask that python 2.6 be a GNOME external dependency. Worth trying, but it seems like a non-trivial request. ii. Use XML instead of JSON. I think this makes most sense, it also answers your goal of accommodating "non-technical people". From looking at the JSON qwerty file it looks like you would get the same level of descriptiveness in XML. iii. Stop calling it JSON :) the syntax, at least in your example would get interpreted fine in python without any json parser. Which option looks good? 1. http://live.gnome.org/TwoPointThirtyone/ExternalDependencies
(In reply to comment #6) Hi Eitan, > Hi. > > I like the level of detail we would get with the JSON format you propose. > > One issue that I see is that the python json module is only bundled python in > 2.6, while the excepted external dependency[1] is python 2.5.2. Oh... Didn't realize that. > > I see 3 options: > i. Ask that python 2.6 be a GNOME external dependency. Worth trying, but it > seems like a non-trivial request. I think this could be tried. 2.6 represents a good improvement from 2.5, of course, it means deprecations warnings and the like will come out from some places and it will need to be fixed... > ii. Use XML instead of JSON. I think this makes most sense, it also answers > your goal of accommodating "non-technical people". From looking at the JSON > qwerty file it looks like you would get the same level of descriptiveness in > XML. This could be done but editing XML is a form of psychological torture imho, and it would represent extra work adapting the file. If you look at the code, the JSON module really makes things easy to encode objects from the JSON syntax. > iii. Stop calling it JSON :) the syntax, at least in your example would get > interpreted fine in python without any json parser. > Same answer as above, the JSON parser comes in handy. > Which option looks good? > I think that if option i is not going to happen, I'd do the XML stuff... Thanks for your comments, -- Joaquim Rocha
Any news on this? I would love to see this functionality in git. If not, then I am tempted to write this myself using XML keyboard definitions.
(In reply to comment #8) > Any news on this? I would love to see this functionality in git. If not, then I > am tempted to write this myself using XML keyboard definitions. Hi Eitan, so is the JSON really impossible to have, according to the things you wrote? I can replace the JSON by XML next week if that's what it takes for the code to be pushed. Cheers, -- Joaquim Rocha
Created attachment 161877 [details] [review] Tarball with the patches to allow the configuration of kb layouts from JSON and XML Hi this set of patches makes it easy and dynamic to configure a keyboard layout using a JSON or XML. It gets the layout file to be used from a GConf key and uses JSON or XML according to the file's extension. The JSON is an optional feature since like Eitan says, the json module is not on GNOME's Python version. These patches do not need the previous patch I sent. Unlike that previous patch, the new changes are separated in more than one patch. Cheers,
Created attachment 161878 [details] QWERTY layout in JSON Hi, this is the new JSON QWERTY layout. As you can see, the format is different than the previous one so it fits more the same format used with the XML one.
Created attachment 161879 [details] QWERTY layout in XML
(In reply to comment #12) > Created an attachment (id=161879) [details] > QWERTY layout in XML Oops, pressed submit before I wrote the comment... This last attachment is the QWERTY layout in XML which will be exactly the same one described in JSON format. To test the files, after applying the implementation patches, set the following GConf to either the layout name (like: qwerty.json or qwerty.xml): /apps/caribou/osk/layout Cheers,
Created attachment 161887 [details] [review] Add keyboard model retrieval from GConf
For future reviews, please either supply a git branch or use git-bz to upload individual patches. Bugzilla now has a nice review feature that doesn't work on tarballs :) (In reply to comment #10) > Created an attachment (id=161877) [details] [review] > Tarball with the patches to allow the configuration of kb layouts from JSON and > XML > > Hi this set of patches makes it easy and dynamic to configure a keyboard layout > using a JSON or XML. It gets the layout file to be used from a GConf key and > uses JSON or XML according to the file's extension. > > The JSON is an optional feature since like Eitan says, the json module is not > on GNOME's Python version. > > These patches do not need the previous patch I sent. > Unlike that previous patch, the new changes are separated in more than one > patch. > > Cheers,
Review of attachment 161887 [details] [review]: The changes overall look good. As far as I am concerned, this patch is the only blocker. ::: caribou/window.py @@ +26,3 @@ +import os + +CARIBOU_GCONF_LAYOUT_KEY = '/apps/caribou/osk/layout' This key path looks good. We need a gconf schema file... @@ +136,3 @@ + conf_file_path = os.path.join(os.curdir, + CARIBOU_LAYOUT_DIR, + layout) This needs to be set up to use either curdir when running from source tree and datadir ($prefix/share/caribou/keyboards) when running from installation. @@ +137,3 @@ + CARIBOU_LAYOUT_DIR, + layout) + print conf_file_path This should go away, add a debug message if needed.
Created attachment 162004 [details] [review] Removed caribou/keyboards Removed the caribou/keyboards folder and all mentions to it in the other files.
Created attachment 162005 [details] [review] Add data/keyboards folder This folder should have the keyboard layouts, in XML or JSON formats.
Created attachment 162006 [details] [review] [window] Use data_path to retrieve the data directory for the layouts
Created attachment 162007 [details] [review] Add caribou.schemas
Hi Eitan, I have attached a few patches that hopefully solve what you pointed before. Cheers,
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.