GNOME Bugzilla – Bug 682636
Interim focus tracking for gnome-shell magnifier via D-Bus
Last modified: 2015-02-27 16:41:08 UTC
Current work (bugzilla 647074) to add a focus/caret tracker to gnome-shell is incomplete. A prime client of that code is the gnome-shell magnifier. As an interim solution, Joanie's proof-of-concept standalone focus tracker app could be added to the pyatspi2 distribution to provide focus tracking for magnifier users who need/want it. Patch forthcoming.
Created attachment 222365 [details] [review] Patch to add focus tracker Patch that adds an "examples" folder to the pyatspi2 project, with the proof-of-concept focus tracker python code. The rationale for an examples folder: when the actual gnome-shell focus tracker is complete, this code can still serve as an example of pyatspi2 usage. It also provides a folder for future pyatspi2 examples.
Review of attachment 222365 [details] [review]: Did you mean to include Sun and Willie Walker in the copyright? Also, I think that the example should go in the tarball, and your patch doesn't do that. Feel free to either add a Makefile or commit as-is.
(In reply to comment #2) > Review of attachment 222365 [details] [review]: Thanks Mike! > > Did you mean to include Sun and Willie Walker in the copyright? Yes, to err on the side of caution. Part of the code was extracted from the now defunct files "gsmag.py and "mag.py", which I traced back as far as the fall of 2009. They were copyrighted Sun and Willie Walker back then, so I figured it still applied. But, I don't know if it's required. > Also, I think that the example should go in the tarball, and your patch doesn't > do that. Feel free to either add a Makefile or commit as-is. Good idea! Although Makefiles are not my forte, I'll poke around pyatpis2 to see if there is something I can copy or add to. Also, I think there is an annoyance in the way the code works -- it stops and exits if the magnifier is turned off via its gsetting. That can happen without the magnifier D-Bus service shutting down. This is annoying if a user turns the magnifier off and then back on for some reason. They lose focus tracking in the process. I think the correct behaviour is: 1. exit if the magnifier D-Bus service stops. 2. register/deregister the focus tracking events in parallel with the magnifier activation toggle. I'll look into those changes as well.
Created attachment 222638 [details] [review] Keep tracker alive across multiple enabling/disabling of magnifier First checks to see if magnifier dbus service is available and quits if it isn't. Thereafter, toggles tracking of focus and caret events as the magnifier's enabled gsetting is toggled, but doesn't quit if magnifier is (temporarily) disabled. Note: this patch is cumulative with the previous one.
Review of attachment 222638 [details] [review]: Looks okay to me.
(In reply to comment #5) > Review of attachment 222638 [details] [review]: > > Looks okay to me. Thanks Mike! I have committed the two patches. I'm having a problem when I click the 'review' link and use the patch review page to change the status of the patches from 'accepted-commit_now' to 'committed'. When I click the "Publish" button to confirm the status change, I get this error: "Failed to publish review: Undefined subroutine &extensions::splinter::lib::WSSplinter::ThrowCodeError called at /var/www/bugzilla.gnome.org/extensions/splinter/lib/WSSplinter.pm line 88." Maybe I don't have sufficient permission to change attachment status?
(In reply to comment #6) > (In reply to comment #5) > > Review of attachment 222638 [details] [review] [details]: > > > I'm having a problem when I click the 'review' link and use the patch review > page to change the status of the patches from 'accepted-commit_now' to > 'committed'. When I click the "Publish" button to confirm the status change, I > get this error: There are extra permissions that are required to change the status of an attachment, so you may not have them. You could trying asking for the permissions in #bugs. But the error that you're getting sounds like a bug in Bugzilla. Anyway, I'll change the status of the attachments.
Created attachment 223453 [details] [review] Attempt to include "examples" folder in the distribution. An attempt to modify "configure.ac", and two "Makefile.ac"s such that the "examples" folder is included in the distribution. This needs a second pair of eyes to confirm that all relevant files are properly modified, and that the result is correct.
Comment on attachment 223453 [details] [review] Attempt to include "examples" folder in the distribution. That looks fine, and it works for me.
(In reply to comment #9) > (From update of attachment 223453 [details] [review]) > That looks fine, and it works for me. Thanks Mike -- committed. As usual, though, I can't mark it the attachment here as committed.
Hi would it be possible to remove the shebang from magFocusTracker.py ? Or set the file to executable if that was the intention? Trying to build latest package for openSUSE I get the following rpmlint warning python-atspi.noarch: W: non-executable-script /usr/lib/python2.7/site- packages/examples/magFocusTracker.py 0644L /usr/bin/python This text file contains a shebang or is located in a path dedicated for executables, but lacks the executable bits and cannot thus be executed. If the file is meant to be an executable script, add the executable bits, otherwise remove the shebang or move the file elsewhere.
(In reply to comment #11) > Hi > > would it be possible to remove the shebang from magFocusTracker.py ? > Or set the file to executable if that was the intention? It's supposed to be executable. The executable bits *are* set on the source file, see: http://git.gnome.org/browse/pyatspi2/tree/examples. Somehow they are lost during the build. I'm trying to figure out why.
Created attachment 224662 [details] [review] Modified the makefile to copy the executable bits. Added an 'example_SCRIPTS' line to Makefile.am that does the trick. But, I'm no makefile guru. Is this the correct approach? What about the .pyc and .pyo files?
We shouldn't be installing into $pythondir/examples, actually. I looked at dbus-python and pygobject to see what they do, and both mark their examples as EXTRA_DIST (ie, they are included in the tarball but not installed anywhere), so I've made that change with the pyatspi sample.
(In reply to comment #14) > We shouldn't be installing into $pythondir/examples, actually. > > I looked at dbus-python and pygobject to see what they do, and both mark > their examples as EXTRA_DIST (ie, they are included in the tarball but not > installed anywhere), so I've made that change with the pyatspi sample. I'm not sure about this, but maybe it's correct. The point of the focus tracker was to provide magnifier users who want/need focus tracking with a simple command line executable. If it's not "installed anywyhere", how do they use it? Put another way: under the EXTRA_DIST scenario, what are the instructions to end users in terms of launching the focus tracker?
Maybe installing it into $bindir (ie, /usr/bin) makes the most sense.
[Mass-resetting default assignee, see bug 705890. Please reclaim this bug report by setting the assignee to yourself if you still plan to work on this. Thanks!]
(In reply to comment #15) > (In reply to comment #14) > > We shouldn't be installing into $pythondir/examples, actually. > > > > I looked at dbus-python and pygobject to see what they do, and both mark > > their examples as EXTRA_DIST (ie, they are included in the tarball but not > > installed anywhere), so I've made that change with the pyatspi sample. > > I'm not sure about this, but maybe it's correct. > > The point of the focus tracker was to provide magnifier users who want/need > focus tracking with a simple command line executable. If it's not "installed > anywyhere", how do they use it? Put another way: under the EXTRA_DIST > scenario, what are the instructions to end users in terms of launching the > focus tracker? Is this resolved?
(In reply to comment #18) > > Is this resolved? Not so much resolved as overtaken by events. This bug is obsolete. The D-Bus focus tracker was an interim solution until focus tracking could be built into gnome-shell. That was your GSOC project last summer, and it has supplanted this interim tracker. A side issue is that the D-Bus focus tracker was built on an older python interface to D-Bus that no longer works. The code would have to be ported to the new interface. Thus, the question about where to install it is kind of beside the point. I'm closing this bug RESOLVED/WONTFIX. If someone sees a real need to (a) port this code to the new python D-Bus API, and (b) determine how to install, feel free to open a new bug.
(In reply to comment #19) > (In reply to comment #18) > > > > Is this resolved? > > Not so much resolved as overtaken by events. This bug is obsolete. > > The D-Bus focus tracker was an interim solution until focus tracking could be > built into gnome-shell. That was your GSOC project last summer, and it has > supplanted this interim tracker. > > A side issue is that the D-Bus focus tracker was built on an older python > interface to D-Bus that no longer works. The code would have to be ported to > the new interface. Thus, the question about where to install it is kind of > beside the point. > > I'm closing this bug RESOLVED/WONTFIX. If someone sees a real need to (a) port > this code to the new python D-Bus API, and (b) determine how to install, feel > free to open a new bug. I do. I was just about to do it and then I realised something important so I have one more question about this as I think if the python is going to be ported it makes sense to create a magnifier module with pyatspi as a dependency rather than tack the work onto pyatspi. Here's why I think it would be useful: KDE, GNOME, Unity all seem to go for the built-into-the-compositor approach. Which is fine, but something sound be available to allow users the freedom to use whatever linux they like. Some may not have the choice either, if they are running a lower spec machine like a netbook or old machine. The python work seems a good candidate Much of the code has already been written (albeit code which needs porting) I am already familiar with the pseudo-code and the gnome shell project work is fresh in my mind. Summary: I would like to propose a new module to develop a standalone python magnifier in using a port of the example work to get things started. Would this be welcomed? If so, what do I file the bug against or who should I propose it to?
[Moving at-spi/pyatspi2 bugs to separate product. See bug 740075]