GNOME Bugzilla – Bug 323648
RFE: better provisions for core pointer mode
Last modified: 2007-02-27 01:05:00 UTC
I know that this topic has been touched on in several other bugs, but I'm opening a new one to present the case a bit differently. I understand that GOK is configured to use separate pointer devices to avoid some users getting stuck when random applications grab the core pointer, esp. when operating it by switches. But there are also users who would want to use it with a single pointer device. This could be using a HeadMouse, or a tablet PC, which looks like an interesting adaptive device for many. Isn't it time to split this problem up to cater better for different user groups in different ways? We could have a 'core pointer' mode that used only the single default pointer and a 'multiple pointers' mode that resisted pointer grabs. Users who can use a head mouse, tablet or a track-ball (but not a keyboard) could benefit greatly from using GOK, but at the moment the application seems broken to them in various ways if only one device is configured. But this group doesn't need protecting from pointer grabs because they would be able to recover by simply clicking on GOK again. Other groups who depend on switches or other more non-standard input devices would likely have several devices connected and would then expect that some configuration was required. The different modes could be catered for with a setup process the first time GOK is run. It could start with a full-screen interface that would reduce the risk of pointer grabs, and would take the user through some settings questions. Then it could be made completely clear what the different modes are used for and the user can configure GOK according to his/her needs.
Thanks Henrik for taking the time to understand the issues. For now, setting this as "new" and adding some related dependancies.
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
Henrik, I have a patch that should largely address this issue on systems where XEvie is enabled. Will post soon.
Hi Henrik - sorry I seem not to have been on the CC list for this bug for the past year (!). Attached is an initial patch which offers much better corepointer mode support when xevie is present. It uses xevie to obtain core pointer events, which makes it immune to pointer grabs and similar side-effects of using the core pointer. It also silences/removes the warning dialogs about core pointer mode when operating GOK in default configuration with xevie. No ChangeLog or comments yet, more to come. Also the patch could use some testing in various non-xevie environments since it seems quite plausible that I have introduced errors somewhere. Best regards, Bill
Created attachment 82118 [details] [review] initial rev of patch to use xevie for good core pointer support. It's not quite 'zeroconf gok' but it's much closer, should make GOK "just work" out of the box (provided xevie is enabled in your x server).
Thanks Bill! I can give this a quite look over probably Friday, but I don't know how soon I can give it a good going over -- maybe 2 weeks?
Does this make the libusb support unnesessary? Or would it still be useful for non-xevie systems? I'm just trying to get a sense of how important the libusb stuff and if it's worthwhile to continue to hack away at it. Perhaps we could come up with a plan to work towards a 'zeroconf gok'. I'm looking for a programming task that I could help out with. thanks.
Ben, you are a ray of hope. Any help you can give us with planning zeroconf gok would be awesome. Do you think you would have time to help review Bill's patch? You libusb solution is definitely not off the table! It might turn out to be the long term winner solution at least on Linux.
Patch applied to CVS. Consider the bug fixed (but xevie must be enabled on host machine, and xevie headers present on build machine).