GNOME Bugzilla – Bug 591034
Caps_lock does not get re-enabled after orca shutdown and when switching from laptop to desktop layout.
Last modified: 2010-09-20 10:52:56 UTC
caps lock does not get re-enabled after orca shutdown also, if user switches back to desktop layout from laptop layout, it should be enabled on the fly. Patch to be attached.
Created attachment 140092 [details] [review] rev 1 Please test. Thanks
Created attachment 140114 [details] [review] rev 2 With this into place, I can provide a patch for (Bug 373387 - Users should be able to lock/unlock the "Lock" modifier even if Caps Lock is the Orca modifier) that allow us to use the pass through to toggle caps lock.
This looks good to me.
Created attachment 140220 [details] [review] Rev 3 Thanks Joanie! Attached is a revised version that should be doing exactly the same as the previous, but more generalized. I wanted it to help us on the fly to determine what modifiers need to be included for (bug 536827 - Provide configuration GUI option to set the Orca key/modifier) (pylints to 10) Reasonable to commit?
doah, included the configure.in into the patch, didnt mean to do that. Sorry
I just now am trying this (Sorry! See the atk bug...). When I launch Orca from the terminal, I see the following lines: xmodmap: unknown command on line stdin:1 xmodmap: 1 error encountered, aborting. When I quit I see: sh: line 1: add: not found
Sorry to be spammy. I also see the above error when I change from the Desktop to the Laptop layout. But more importantly, having switched to the Laptop layout and pressed the Apply button, Caps_Lock is functioning as the Orca modifier along with toggling the lock. So I wind up typing in all caps when that's not what I intend to be doing. I'll leave it to Will to do the official review since this patch has grown more complicate than the last version. From a functional point of view, however, it needs work I'm afraid. I'm really sorry, Jon! And thanks again for all your effort on this bug. Once things are sorted out, this will be great functionality.
Created attachment 140282 [details] [review] Revised patch This is a revised patch that isolates things to orca.py and seems to fix the problems Joanie has identified (I hope!). I think the problem was that the earlier patch tried to do a number of changes with a single xmodmap command, which didn't make some systems happy. Joanie - can you give this a quick check?
From the perspective of a "quick check" (OpenSolaris dev build 118), it all seems to work.
I made the executive decision to push this out to at least 2.27.91 since I think it needs more soak time.
please see patch.373387-2 which includes patch for this bug.
Created attachment 140676 [details] [review] rev 5 Just discovered git add -p, Very useful indeed. Patch that solves the issue in question. Thanks
I wrestled with this one. The impact of this bug seems to be mostly on public information systems where the system could be left in a state where the CapsLock modifier is left unbound. In most other cases, it's likely to be a single user machine and the single user would be an Orca user running Orca full time. So, the bug of not resetting the CapsLock modifier in some cases is indeed a bug, but not one that is huge (which is why this is marked as minor). The code changes are kind of big for this, so I put this bug in more of the "high risk"/"low impact" category, which is stuff we want to do early in the release cycle versus the end. I'm going to push this one out for FUTURE and we'll take a poke at it early in the 2.29.x cycle.
Created attachment 160154 [details] [review] Patch file to try and trace how Orca quites Added print statements to try to trace how orca quites. When we quit Orca from the GUI, we see this: Orca Shutdown launched from quitOrca() Orca Shutdown launched from shutdown() When we quit Orca with 'orca-q' or '--replace', we see this: Killed Joanie, does this means that no clean up code is been run? thank you Tom and John
Hi, according to: http://aplawrence.com/SCOFAQ/FAQ_scotec6killminus9.html and http://linux.die.net/man/7/signal we should be trying to handle kill -15 (the standard kill) first, which would run the cleanup code as expected. Joanie: in src/orca/orca.in, cleanup(), we use kill -9 If we used kill, our cleanup code in orca.py would be run. and we could have --force that would do the kill -9 for when orca really has hung. (separate bug, but it blocks this one) Sounds reasonable? Thanks -Jon
(In reply to comment #15) > Hi, > > according to: > http://aplawrence.com/SCOFAQ/FAQ_scotec6killminus9.html > and > http://linux.die.net/man/7/signal > > we should be trying to handle kill -15 (the standard kill) first, which would > run the cleanup code as expected. > > Joanie: > in src/orca/orca.in, cleanup(), we use kill -9 > If we used kill, our cleanup code in orca.py would be run. > and we could have --force that would do the kill -9 for when orca really has > hung. > (separate bug, but it blocks this one) > Sounds reasonable? I think so. I'd like to try it on my systems before you commit (to get the OpenSolaris coverage), but sure. Go for it.
Created attachment 161221 [details] [review] Rev 6. Hopefully this is a good one. Now that bgo#618285 is closed, this provides all the functionality that i wanted from this fix. Joanie, does things look ok? pylinted to 10
It's working nicely for me in OpenSolaris. If you're comfortable with it, I say go ahead and commit it to master and let the users pound on it.
Done. Thanks