GNOME Bugzilla – Bug 101141
GOK's settings dialog for actions needs refactoring.
Last modified: 2004-12-22 21:47:04 UTC
GOK's "Actions" page from the settings dialog is pretty confusing and even misleading now, since the distinctions between 'switch' and 'mouse' devices are very blurry. For instance, "mouse" doesn't mean a physical mouse device anymore, or even a mouse driver, and it doesn't necessarily mean "core pointer" either. The changes to GOK to support XInput device make this situation worse. Calum and I are looking at this too; I'm sure he'll have suggestions. In any case, the existing use of "action names" as an abstraction layer won't be affected, what needs rework is the means of specifying which devices (from the system perspective - there's no way of knowing what physical devices are attached to device drivers) are associated with GOK actions. I suggest: * we coalesce the "mouse pointer" and "dwell" concepts somewhat, at least when selecting an action "device type" - so that both dwell and pointer actions are "pointer" types. Thus an action named "dwell" can use input device "corepointer", "usbtrackball", "eyetracker", etc. and from there the user can determine how said pointer is interpreted. * we combine 'mouse button' and 'switch' sections, since from the user perspective the two are the same; we could even include 'keys' in this section (just calling it "switches"). * the "pointer" and "switch" sub-sections are controlled by the choice of input device, not the "action type", since for a given input device a subset of the above action types will be available. * we should include "corepointer" and/or "joystick" in the device selection proces, either by including them in the "Input Device" dropdown box, or by including radiobuttons for 'joystick', 'core pointer', and 'other [dropdown list]'. * we should allow the user to specify a switch or key for an action via a dialog rather than forcing the user to select a switch or key number from a list; thus the user can be prompted to 'press a switch to select it' and gok-settings can figure out which internal button or key number to associate with the named action. Of course the result can still be reported in an editable field, so that savvy clinicians can fill the form in directly. This implies that the business of creating or editing an action goes like this: select_action_name->select_input_device->select_button/pointer followed immediately by selecting "press" or "release" for buttons, "dwell", "dwell time", etc. for pointers, and delays for both. -Bill
This work is in-progress; I have something that Calum and I have worked out after substantial discussion. The remaining work is wiring it into the actual GOK data/behaviors.
I attach my current patch for this.
Created attachment 14895 [details] [review] initial patch to fix UI and connect it to GOK
note that the patch has some moderate-impact bugs, but no regressions that I am aware of. By bugs, I mean, for instance: the dialog infers that an extended input device may be associated on a per-action basis. Although that is the plan, at the moment it isn't true, and all 'xinput' events are connected to the most-recently-specified xinput device. in practice that's not a regression, and use of multi-xinput devices is not too common. But to avoid terrible churn in the UI, the feature is presented in the UI. We should at least document this in the README or config guide; should probably fix to use actual per-action input devices before "1.0".
making sure these bugs have PATCH keyword
Created attachment 14996 [details] [review] updated patch against HEAD
David/Simon: I'd like to apply this patch now. Can you give the go-ahead? We can then deal with any outstanding issues with the behavior.
Added gnome-access-bugs@basso.sfbay.sun.com to CC list.
Bill, Just a heads up. Your patch doesn't seem build with gok head. One of the build targets in the Makefile refers to keyboard-geometry.c, which doesn't exist in cvs. I'm working around it to test the patch...
well, this patch is getting rather old, it was last updated nearly a month ago. I attach a new version against HEAD.
Created attachment 15567 [details] [review] latest version of gok patch, against CVS HEAD
Created attachment 15568 [details] source code for keyboard-geometry.c, as required by the patch
I attached keyboard-geometry.c also; I am having some difficulty getting cvs diff to include the source file in the patch so it's provided separately. I do think it's worth having keyboard-geometry.c in the CVS files and tests, since troubleshooting the XkbGeometry stuff can be fairly ugly without test code.
Okay I'm looking thanks.
Great. I think this is good progress. Please commit. Some comments/questions: 1. What is the valuator group box? 2. Is anyone pursuing the per action assignment of xinput devices you talked about earlier? 3. What is the purpose of the new action type: ACTION_TYPE_VALUECHANGE? It appears not to be used/hooked-up yet? 4. I tested only on RH8 with G2.2 from the March 27 tarball.
Hi: The new pieces of the valuator UI are there so that a valuator (from an XInput device) can be assigned either to be an X-Y pointing device, or a one-dimensional valuator (i.e. like a dial). In the latter case the action type would be ACTION_TYPE_VALUE_CHANGE. So one could define a new action which resulted from a valuator motion (such as moving a slider or dial on an input device) which was not a pointing action. We don't use these actions yet, but of course we could, for instance a dial or slider could be used to control row selection, etc., etc. thanks David!
All these changes are in now, right?
yes, they are in. closing.