After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 323648 - RFE: better provisions for core pointer mode
RFE: better provisions for core pointer mode
Product: gok
Classification: Deprecated
Component: settings
Other All
: Normal enhancement
: ---
Assigned To: David Bolter
David Bolter
Depends on: 319735 322655
Reported: 2005-12-09 17:28 UTC by Henrik Nilsen Omma
Modified: 2007-02-27 01:05 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12

initial rev of patch to use xevie for good core pointer support. (15.48 KB, patch)
2007-02-07 21:21 UTC, bill.haneman
committed Details | Review

Description Henrik Nilsen Omma 2005-12-09 17:28:20 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.
Comment 1 David Bolter 2005-12-12 17:08:56 UTC
Thanks Henrik for taking the time to understand the issues. For now, setting 
this as "new" and adding some related dependancies. 
Comment 2 Calum Benson 2006-04-26 17:11:41 UTC
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
Comment 3 bill.haneman 2007-02-06 18:52:31 UTC
Henrik, I have a patch that should largely address this issue on systems where XEvie is enabled.  Will post soon.
Comment 4 bill.haneman 2007-02-07 21:11:37 UTC
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,
Comment 5 bill.haneman 2007-02-07 21:21:37 UTC
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).
Comment 6 David Bolter 2007-02-07 22:55:52 UTC
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?
Comment 7 Ben Konrath 2007-02-07 23:07:00 UTC
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.
Comment 8 David Bolter 2007-02-07 23:17:28 UTC
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.
Comment 9 bill.haneman 2007-02-27 01:05:00 UTC
Patch applied to CVS.  Consider the bug fixed (but xevie must be enabled on host machine, and xevie headers present on build machine).