GNOME Bugzilla – Bug 537827
Make GOK work with core pointer
Last modified: 2008-12-03 01:16:59 UTC
As per IRC discussion. GOK's requirement for a secondary non-core pointer device has caused endless confusion and grief. As a step towards alleviating this a GOK core pointer mode needs to be developed.
Created attachment 112557 [details] [review] initial fix This is a first pass solution which seems to work. I'll investigate further to see if I can make the delta smaller (find a single point for checking corepointer mode).
Note you need to run gok --use-corepointer to test this out.
I checked out the current trunk of gok, applied your first patch, compiled and installed it. It is a remarkable progress: when I call it with the --use-corepointer flag, I am able to use it in direct selection mode and dwell selection mode, it highlights the correct keys (not the keys of the line above). But there are issues left: - When started during gdm in dwell selection mode, an information window appears informing the user that sticky keys have been enabled. It is impossible to close this window. In fact, when the window appears, the pointer is inside this window; to move the pointer to the gok window, it has to pass over the gdm window and gok changes to the ui of gdm and the buttons of the information window are not available anymore. - I had to remove the --login flag from the start command; gok did not start up when using the --login flag and --use-corepointer flag simultaneously. - When I start it for example from the application menu, I am not able to use it. (I have to start it from the terminal with the --use-corepointer flag by using onboard.)
I tested the latest gok trunk with the new patch. In my opinion is awesome, it works really really great (out of the login :P). I'll explain: First in the session i launched: gok --use-corepointer --access-method=dwellselection and i had no problems to use gok, the core pointer patch worked perfectly. Now in the login I tested this three ways: 1) gok --use-corepointer --access-method=dwellselection (Gok doesn't start) 2) gok --login --use-corepointer --access-method=dwellselection : Gok starts and the dwell works perfectly but gok doesn't write in the textbox, even if i click the buttons with the mouse. the textbox was focused and it worked with the normal keyboard. 3) gok --login --access-method=dwellselection : gok starts but is difficult to focus the keys and as the previous test gok doesn't write in the textbox. I hope this helps!! Cheers P.D: Good Work!!
That is strange: on my system (Ubuntu 8.04.1 and Ubuntu Intrepid) it starts only if there is no --login flag; on Flavio's system it starts only with the --login flag. Flavio: did you uninstall the previous gok version? On my system the manually installed version has been installed under /usr/local/bin. Did you remember to update the /etc/gdm/modules/AccessDwell... file?
indeed I had the same problem, i mean, I didn't know that it was installed on /usr/local/bin until i found out that the --use-corepointer flag wasn't working. then I uninstalled the previous version and installed the new one to /usr. I checked the /etc/gdm/modules/Access... file and modified it directly to test the three methods. Gok still doesn't write even if the keys are highlighted. I'm using Archlinux.
If somebody has an idea about how to better center the issue, please let us know.
Hey! Seems to work well for me for login with both directselection and dwellselection. This is with just GOK (i.e., not GOK + MouseTweaks). Here's what I did: 1) Built/installed GOK from trunk with the patch on my Solaris box. 2) Modified my GDM files: bash-3.2$ grep corepointer /etc/X11/gdm/modules/* /etc/X11/gdm/modules/AccessDwellMouseEvents:TBLR I 10000 /usr/bin/gok --use-corepointer --login --access-method=dwellselection /etc/X11/gdm/modules/AccessKeyMouseEvents:<Mouse1> 3 3000 10000 /usr/bin/gok --use-corepointer --login --access-method=directselection /etc/X11/gdm/modules/AccessKeyMouseEvents:<Mouse3> 3 3000 10000 /usr/bin/gok --use-corepointer --login --access-method=directselection /etc/X11/gdm/modules/AccessKeyMouseEvents:<Control>k 1 1000 10000 /usr/bin/gok --use-corepointer --login --access-method=directselection 3) Logged out. 4) At the gdm screen, pressed Ctrl+k for a second to start GOK in direct selection mode. I'll admit this is a nonsensical gesture for the user in question, but it is what I used to start GOK. With this, I was able to click on the keyboard and log in. I use various symbols and such in my password that require me to latch the Shift key. Worked great. 5) Logged out. 6) At the gdm screen, did the top-bottom-left-right mouse gesture to start GOK in dwell selection mode. With this, I was able to dwell on the keyboard and log in. Again, the latching of the Shift key worked great. While I kind of have the hang of using GOK via a switch, this is the first time I've actually felt like I was using GOK comfortably via the pointer. That is, I didn't have this feeling of wondering what mysterious thing GOK was going to do next. It actually just worked. Wow! David, if we can resolve Flavio's issues, I think I would definitely try to opt for making --use-corepointer the default, and I would opt for doing this in trunk and the GNOME 2.22 branch (if there is one). The only question in my mind would be if anyone in the existing user base would end up being harmed as a result. Thanks for the nice work! What a quick and small patch, too!
Thanks so much everyone! So is this the currents status: WW: works great FF: gok won't start with --login flag FP: gok doesn't seem to send keystrokes to the text field ? I've slotted some time on Monday with my new linux workstation to wrap this up. I hope I can catch you guys on #a11y (and hopefully I'm not late this time). In the meantime, let's update each on how things are working if there are changes. Shall I change the flag to --not-corepointer, so that no flag defaults to core pointer usage? That seems to be the consensus.
(In reply to comment #9) > Thanks so much everyone! > > So is this the currents status: > > WW: works great > FF: gok won't start with --login flag > FP: gok doesn't seem to send keystrokes to the text field Keep in mind I'm on Solaris. Linux distributions historically get accessible login all wrong. > Shall I change the flag to --not-corepointer, so that no flag defaults to core > pointer usage? That seems to be the consensus. Hey - I'm for that since it will make GOK 'just work' with GDM without needing to change any gdm config files. You are the GOK guru, though, and would better understand the impact on end users.
> Keep in mind I'm on Solaris. Linux distributions historically get accessible > login all wrong. I'm still working on it with Ubuntu :-( > > Shall I change the flag to --not-corepointer, so that no flag defaults to core > > pointer usage? That seems to be the consensus. > > Hey - I'm for that since it will make GOK 'just work' with GDM without needing > to change any gdm config files. You are the GOK guru, though, and would better > understand the impact on end users. +1 and I'm guessing it will mean casual users who just install and try it with the mouse might stay interested longer. Hey it might even make it back into Ubuntu ;-)
(In reply to comment #10) > Keep in mind I'm on Solaris. Linux distributions historically get accessible > login all wrong. > I'm working on Arch Linux > > Shall I change the flag to --not-corepointer, so that no flag defaults to core > > pointer usage? That seems to be the consensus. > > Hey - I'm for that since it will make GOK 'just work' with GDM without needing > to change any gdm config files. You are the GOK guru, though, and would better > understand the impact on end users. +1 We should work always for the best configuration and use it as the default configuration. Good job... P.S: I tried starting an xterm but it just doesn't start. Can any of you start an xterm at the login?
@Willie: Was Sticky Keys active during the gdm session before you started gok? I am asking because the dialog informing the user that gok has turned on Sticky Keys is a show stopper for people that are using gok in dwell selection mode. (I don't get that dialog during the gnome session; the reason is that Sticky Keys are active before I start gok (a left over from running gok previously); if I disable Sticky Keys before starting gok, I get that dialog also in the gnome session. By the way, I wonder how the other osks latch the modifier without using Sticky Keys; maybe it is not related to Sticky Keys.) @ Flavio xterm does not startup here either during gdm; maybe that providing determined flags will make it startup. (only an idea without real background) @ David If we are not going to make corepointer the default mode, I think that non-initiated people will still think that gok is broken. What about a dialog to inform people what is going on. I suppose that the main difficulty will be to create a dialog that works simultaneously with the corepointer and with the extended device; as it will be this dialog to decide whether gok has to work in corepointer or extended device mode. And will this be the only difficulty? Another approach might be to create two different gestures/items in the Accessibility Dialog, but this only occurred to me now. It has to be thought through in detail.
(In reply to comment #5) > That is strange: on my system (Ubuntu 8.04.1 and Ubuntu Intrepid) it starts > only if there is no --login flag; on Flavio's system it starts only with the > --login flag. I can confirm that it only works for me with out the --login flag. I tested this in a terminal on desktop first. However I hit another problem at login when running GOK (with ctrl K) I get an error saying 'Assistive technology is not enabled'. Perhaps related to http://bugzilla.gnome.org/show_bug.cgi?id=524263 or is it somethign to do with not having the --login option?
(In reply to comment #13) > @Willie: > > Was Sticky Keys active during the gdm session before you started gok? I am > asking because the dialog informing the user that gok has turned on Sticky Keys > is a show stopper for people that are using gok in dwell selection mode. Yes that sort of modal work flow blocker is a pain. Is GNOME working to remove this sort of thing like Mozilla have in Firefox (e.g panel notifications)? One thought is that if the GDM AT options passed on to the desktop then it will not always be necessary to prompt the users. Do I remember so ideas to play nice with sticky keys rather than force it on and off?
(In reply to comment #13) > @Willie: > > Was Sticky Keys active during the gdm session before you started gok? I am > asking because the dialog informing the user that gok has turned on Sticky Keys > is a show stopper for people that are using gok in dwell selection mode. I double checked and I don't see any evidence of StickyKeys being active at the login screen. Perhaps the --login switch prevents this dialog from appearing?
(In reply to comment #14) > However I hit another problem at login when running GOK (with ctrl K) I get an > error saying 'Assistive technology is not enabled'. Perhaps related to > http://bugzilla.gnome.org/show_bug.cgi?id=524263 Yep - bug #524263 is separate from this one, and it hopefully has been resolved. With that bug fixed, I think we can start pushing to make a11y enabled by default.
(In reply to comment #16) > (In reply to comment #13) > > @Willie: > > > > Was Sticky Keys active during the gdm session before you started gok? I am > > asking because the dialog informing the user that gok has turned on Sticky Keys > > is a show stopper for people that are using gok in dwell selection mode. > > I double checked and I don't see any evidence of StickyKeys being active at the > login screen. Perhaps the --login switch prevents this dialog from appearing? Makes sense as I had to remove that option and DID see the sticky keys dialog. (I know, should check the code).
Created attachment 112847 [details] [review] system mouse use is default With this patch gok uses the system mouse by default; also contains possible fix that allows GOK to run in login mode even when bonobo fails.
I checked out the current trunk of gok, applied the patch dated 2008-06-16 16:05, compiled and installed. Here are the gestures that I used to start gok during gdm: TBLR I 10000 /usr/local/bin/gok --login --access-method=dwellselection TBRL I 10000 /usr/local/bin/gok --login --access-method=directselection goks works and behaves properly in dwell selection mode and in direct selection mode. The core pointer mode seems to be the default, as I did not specify what pointer mode (extended or core) to use. The Sticky Keys information dialog does not start up anymore during gdm; maybe that Willie's supposition about the dialog not showing up because of the --login flag was right.
(In reply to comment #20) > The Sticky Keys information dialog does not start up anymore during gdm; maybe > that Willie's supposition about the dialog not showing up because of the > --login flag was right. > That supposition is correct.
(In reply to comment #20) > I checked out the current trunk of gok, applied the patch dated 2008-06-16 > 16:05, compiled and installed. > > Here are the gestures that I used to start gok during gdm: > TBLR I 10000 /usr/local/bin/gok --login --access-method=dwellselection > TBRL I 10000 /usr/local/bin/gok --login --access-method=directselection I used <Control>k 1 1000 10000 /usr/local/bin/gok --login --access-method=directselection > goks works and behaves properly in dwell selection mode and in direct selection > mode. direct selection is great but I get a single button saying menus - is that correct? I can't see how to get at login editbox etc > The core pointer mode seems to be the default, as I did not specify what > pointer mode (extended or core) to use. +1 specifying --use-corepointer now is an error > The Sticky Keys information dialog does not start up anymore during gdm; maybe > that Willie's supposition about the dialog not showing up because of the > --login flag was right. +1
at desktop: <Control>k 1 1000 10000 /usr/local/bin/gok --login --access-method=directselection gives only single 'menu' button dropping --login makes it work
That's bound to be this little change.. I'll need to rethink: @@ -638,7 +648,8 @@ if (ret != Bonobo_ACTIVATION_REG_SUCCESS) { if (gok_args.is_login) - return 1; + g_warning ("GOK running in login mode with a failed bonobo activation"); + /* return 1; */ else { gchar *reason = NULL; if (ret == Bonobo_ACTIVATION_REG_ALREADY_ACTIVE) reason = "already active";
(In reply to comment #23) > at desktop: > > <Control>k 1 1000 10000 /usr/local/bin/gok --login > --access-method=directselection > > gives only single 'menu' button > > dropping --login makes it work > Steve can you try this from an xterm at login and see if you get the "GOK running in login mode with a failed bonobo activation" warning?
> Steve can you try this from an xterm at login and see if you get the "GOK > running in login mode with a failed bonobo activation" warning? yes I do
More on --login --access-method=directselection .... On the Ubuntu desktop the trunk version does nothing The second patch does work but gives the little menu button and the following errors ** (gok:14656): WARNING **: GOK running in login mode with a failed bonobo activation ** (gok:14656): WARNING **: Keyboard Geometry cannot be read from your X Server. ** Message: using access method directselection /dev/js0: No such file or directory So should login work at the desktop or not?
David having had a look at the code it's not immediately clear why the keyboard is wrong for your patch. There are many side effects of --login and non corepointer but perhaps the most likely is that a different key board is used if (gok_args.is_login) { gok_args.mainkeyboardname = (gchar*) g_strdup ((gchar *) GOKLOGINKEYBOARDNAME); or perhaps if (gok_data_get_drive_corepointer ()) { Display *display; GdkWindow *root; display = GDK_WINDOW_XDISPLAY (window->window); root = gdk_screen_get_root_window (gdk_drawable_get_screen (window->window)); XWarpPointer (display, None, GDK_WINDOW_XWINDOW (root), 0, 0, 0, 0, motion_data[0], motion_data[1]); } as that could effect the UIGrab. I'm wondering if you might need to call gok_data_set_drive_corepointer() ? oh you might like to add args->nonsystemmouse = 0; to gok_args_init () finally I don't really like usenonsystemmouse as an option as the user might not be using a mouse it could be a head pointer etc. I vote for pointer. Sorry not to be much help
@SteveLee Thanks! You are a help for sure.
Closing as fixed with recent commit (rev 2492). Thanks everyone!