GNOME Bugzilla – Bug 468374
Problems with items occupying the same space as the zoomer window in Ubuntu Gutsy
Last modified: 2007-09-29 00:44:38 UTC
Steps to reproduce: 1. Launch Orca, enable magnification, and set up your zoomer window so that it occupies the left half of your screen. 2. Press Alt F1 to get into the Applications menu. Down Arrow to one of the menus under Applications and then Right Arrow to expand it. Expected results: The menus and items that gain focus would be magnified. Actual results: 1. The menus appear unmagnified on top of the zoomer window. 2. The zoomer window turns solid grey/white (i.e. and displays nothing), OR it doesn't change (i.e. it continues to display whatever it was displaying before). Notes: 1. We saw this sort of thing in Ubuntu Feisty prior to the latest update to gnome-mag in svn trunk. Now this problem doesn't occur in Feisty. 2. This problem did not occur in Ubuntu Gutsy until quite recently. We haven't changed anything in Orca recently with respect to magnification. So I would guess that it's either a change in gnome-mag or a change in something else in GNOME 2.19 (metacity? xorg??). 3. If I launch magnifier before launching Orca, this bug does not occur. It only occurs when Orca is the one to start magnifier.
Aha! This seems to be a side effect of the fix to gnome-mag bug 462890. I reversed the patch to that bug in Gutsy and the menus were displayed and magnified as expected. Carlos given that your original fix is fine (and seemingly side effect free) in Ubuntu Feisty but not in Ubuntu Gutsy, something addition must be coming into play here (X11 stuff?). But I'm not sure how to proceed. Is this something you can fix on your end?
The actual results described appear that the COMPOSITE extension isn't being used. If when you start the magnifier stand-alone this bug doesn't appear I think that in the Orca configuration the target and source displays are different, since with this kind of configuration COMPOSITE isn't used. Can you verify this?
Carlos, on my laptop (i.e. single head box), I would think that the target and source displays would have to be the same by definition. But to confirm, I put some debugging statements into mag.py comparing these two. They are indeed the same. Then I manually set them both to be :0.0 via Orca Preferences. No difference. :-(
you are right, when there is only one head, setting target and source there is no effect. The only think that I can realize for now is that there is some regression in /usr/lib/bonobo/servers/GNOME_Magnifier.server file, since when calling magnifier standalone it's not activate throw bonobo, but when started throw orca bonobo activation is used. See if in the file above there is a line --ignore-composite (probably the third line "type="exe" location="/usr/bin/magnifier --ignore-composite">". If this is not the case I will have to download Gutsy, since I don't have it yet.
I don't have an --ignore-composite line: <oaf_server iid="OAFIID:GNOME_Magnifier_Magnifier:0.9" type="exe" location="/usr/bin/magnifier"> If downloading Gutsy is something you're willing to do, that would be awesome! GNOME 2.20 is rapidly approaching and I'd really like to see Orca and Magnifier working well together. Thanks much for all your help!
I tested here with Ubuntu Gutsy - Tribe 4 test release and I don't have this problem. The magnifier work quite well. Although I have other problems. If I leave the source and target display blank the magnifier work. If I put :0.0 in both the magnifier doesn't work anymore. I also get trash in the magnifier window in the second time, and on, I open orca, but this appear to be a bug that also appear in Feisty, so I will open a bug against it in gnome-mag.
Carlos: If you * use Orca to start magnifier (i.e. do not launch it separately) * leave source and target blank * set up the zoomer so that it occupies the left half of the screen (and thus covers the Applications menu) When you press Alt F1 you are finding that the Applications menu is magnified appropriately? If so, I'm wondering what's different about our configurations. On both of my Gutsy boxes, it appears unmagnified. On my mono-head Solaris box (when I press Control Escape), it appears magnified, but an unmagnified copy of the menu appears on top of the Zoomer window. Again, any ideas would be much appreciated! Thanks!
Created attachment 94687 [details] gnome-mag started by orca running in gutsy This is a screenshot of how the magnifier works here. As you can see, everything is fine. This is gnome-mag 0.14.6. I saw that I can update to 0.14.8... I will update it as soon as I can, since I also note a bug that appear related with damage events, so I can investigate this.
Created attachment 94948 [details] screenshot without the fix to bug 462890 If I reverse the patch to bug 462890, things are magnified as I expect.
Created attachment 94950 [details] screenshot with the fix to bug 462890 If I apply the patch to bug 462890 (or get the latest gnome-mag), things are NOT magnified as I would expect. I can reproduce this on both of my Gutsy boxes. Ideas welcome. Thanks!
Just tested with gnome-mag HEAD and it's work just fine. Can you attach the output of the command "xdpyinfo" from your machines and the ~/.orca/user-setting.py being used in they?
Created attachment 95011 [details] laptop info requested by Carlos Here are the requested files for my laptop.
Created attachment 95013 [details] Desktop info requested by Carlos And here are the Desktop versions. Thanks VERY much for your help Carlos!
Hmmm... I think that you are testing with a different version of Orca than me. This is the only place (orca version) that I can realize where this problem can be. Your X configurations appear to be fine (I had X troubles with Tribe Test 5, so I asked these). So, what version of gnome-mag and Orca are you using? I will test with these when I arive home this night. Thanks for the attention and informations!
(In reply to comment #14) > So, what version of gnome-mag and Orca are you using? Latest trunk builds of each. > Thanks for the attention and informations! Thank YOU. I'm really stumped.... :-(
I think that I done something wrong when I test with gnome-mag HEAD, since now I was able to reproduce the bug. I also find where is ther error. In the magnifier/magnifier.c, function magnifier_properties_init there is this line of code: display_env = getenv ("DISPLAY"); The getenv call is returning :0 and DISPLAY is actually :0.0 I'm now in a machine with Fedora Core release 6 (Zod) and write a small program to test this and the DISPLAY value is just returned right. I will test the same program in the machine with Gutsy. If the simple program return a wrong string the bug appear to be in the getenv call, what I think that have low probability to be.
Created attachment 95094 [details] here is the test program that I use to print the DISPLAY variable
Carlos, for another data point, I just ran your program on my Ubuntu Gutsy machine and got: $ ./testit :0.0
Yeah, I get :0.0 as well on the Gutsy machines in question.
Very interesting. In the first post Joanmarie affirmed that everything works if the magnifer is started before orca, so I believe that the getenv call cited above works right. If someone can test it I will be very gratefull. I try to find something related with DISPLAY in the last tarball of orca and in svn (throw web, what's terrible), but it doesn't appear to do any modification in this variable. You are closer to the code Rich, do you know if something have changed in orca trunk related with the DISPLAY variable?
Well, I'm not Rich... :-) After this call in mag.py _magnifier = bonobo.get_object("OAFIID:GNOME_Magnifier_Magnifier:0.9", "GNOME/Magnifier/Magnifier") :0 is returned for both _magnifier.SourceDisplay and _magnifier.TargetDisplay. Is that what we should be getting, or should we be getting :0.0?
BTW, if I launch magnifier and then launch Orca, :0.0 is returned for both _magnifier.SourceDisplay and _magnifier.TargetDisplay.
> You are closer to the code Rich, do you know if something > have changed in orca trunk related with the DISPLAY variable? I'd say Joanie is much closer to this stuff from an Orca perspective than I am. > After this call in mag.py > > _magnifier = bonobo.get_object("OAFIID:GNOME_Magnifier_Magnifier:0.9", > "GNOME/Magnifier/Magnifier") > :0 is returned for both _magnifier.SourceDisplay and _magnifier.TargetDisplay Joanie, what happens if you "fudge" it to be "0.0" at that point?
> Joanie, what happens if you "fudge" it to be "0.0" at that point? The reported values change, but the original bug remains.
I added some more debugging statements to Orca and gnome-mag and even bonobo for good measure. When I ask for the DISPLAY environment variable anywhere *except* from within gnome-mag, I get the expected :0.0. In gnome-mag, I see the error Carlos indicated. I also see it in main () of magnifier-main.c. I set my Orca Preferences so that the source and target displays were both :0.0 and restarted Orca. 1. In mag.py's init() a check at the beginning reveals DISPLAY == :0.0 (which is the case even if you don't set displays in Orca Preferences) 2. We activate magnifier via bonobo. Apparently bonobo activation takes place without specifying the source or target displays (??) and as mentioned above, in gnome-mag, getenv ("DISPLAY"); returns :0 if started via bonobo activation. 3. Back to mag.py's init(), another check of DISPLAY reveals it's still :0.0, but our source and target displays are now officially :0. 4. Because I have settings for source and target to both be :0.0, Orca then sets the source and target displays to be :0.0. But, like I said in my last comment, at this point it seems to be too late. How can we activate gnome-mag via bonobo with specified source and target displays? And if we can't.... Is there an alternative fix for bug 462890?
I just put some comments in bug #4272992. Now we just need that they fix this before hard code freeze. If I had time I will try to verify where the bug is tomorrow. If someone can investigate it soon it will be very good, since as fast a patch is ready the better it is! Joanmarie, I just have to thank you one more time for giving so many tracks to find it, without you this bug would be far from the solution!
From Will in IRC: > from http://linux.die.net/man/1/bonobo-activation-server: > "Bonobo-activation-server executes all components with the > environment inherited from the first process to start the server." > So, if DISPLAY is whacked in the first process to start the server, > it's whackiness will persist. Then he had me change the exe line to a shell script so that we could get a listing of my environment. Here's what I got: USER=jd SSH_AGENT_PID=15089 HOME=/home/jd XDG_SESSION_COOKIE=740de6336e817ca43693640046c5b700-1189135190.598469-1417763163 DESKTOP_SESSION=default.desktop GTK_RC_FILES=/etc/gtk/gtkrc:/home/jd/.gtkrc-1.2-gnome2 GDM_XSERVER_LOCATION=local LOGNAME=jd USERNAME=jd WINDOWPATH=7 GDM_LANG=en_US.UTF-8 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games DISPLAY=:0 LANG=en_US.UTF-8 XAUTHORITY=/home/jd/.Xauthority SSH_AUTH_SOCK=/tmp/ssh-olevN15052/agent.15052 SHELL=/bin/bash GDMSESSION=default.desktop PWD=/ XDG_DATA_DIRS=/usr/local/share/:/usr/share/:/usr/share/gdm/ So it's whacked and persisting I guess....
> I just put some comments in bug #4272992. Now we just need that they fix this > before hard code freeze. I'm sorry, which bug #?
Ow, sorry, bug #427992 http://bugzilla.gnome.org/show_bug.cgi?id=427992
(In reply to comment #25) [...] > How can we activate gnome-mag via bonobo with specified source and target > displays? This is now possible (since GNOME 2.6 IIRC), via the bonobo:environment oaf attribute: <oaf_attribute name="bonobo:environment" type="stringv"> <item value="DISPLAY"/> </oaf_attribute> As documented in http://library.gnome.org/devel/bonobo-activation/unstable/attribute-tag.html
Created attachment 95176 [details] [review] Patch accordingly with Gustavo's tip From my POV, this is not the right fix for the problem, although if we doesn't find the root of the problem I think that this an acceptable solution.
@Gustavo: Thanks much!! As you probably gathered from my comments, I'm still quite new to all of this with a lot to learn and read. I will definitely be reading those docs and appreciate the pointer. @Carlos: > find the root of the problem I think that this an acceptable solution. Well.... I just tried it on my desktop (tri-head Xinerama box) and two things happened: 1. Orca crashed once (see error below) and hung the other time. 2. Magnifier hung both times. I haven't yet tried this on my laptop because at this very moment I'm doing clean installs for some testing we're getting started on. Regardless.... If this approach winds up being the route we have to take, it would seem that we have a bit more debugging to do first. :-)
+ Trace 161386
init(registry)
loadUserSettings()
mag.init()
"GNOME/Magnifier/Magnifier")
debug.printStack(debug.LEVEL_ALL)
traceback.print_stack(None, 100, debugFile)
Someone else can also test with the patch of my last comment? I test it here and the magnifier worked properly. @Joanmarie: I don't know if what you're getting is due your tri-head Xinerama box (specially due Xinerama, since gnome-mag works in a dual-head configuration). Could you try gnome-mag in a single-head desktop or in a dual-head desktop (using two video cards or a dummy video card)? I can't configure X in Gutsy with a dummy video card. I will report this to their bug track system.
I'm committing this, since I believe the error Joanmarie is getting have some other source. If someone want to re-open this with new evidences, feel free.
This seems to work on my laptop and on the tri-head system when Xinerama is NOT enabled. If Xinerama is enabled and the composite extension also used, CPU usage spikes to 100% :-(
Just FYI: bug #475805 I will try to address it, but since I don't have the hardware needed to configure a Xinerama desktop it can take some time.
(In reply to comment #34) > I'm committing this, since I believe the error Joanmarie is getting have some > other source. If someone want to re-open this with new evidences, feel free. > In Ubuntu Gutsy or OpenSolaris, disable composite in xorg.conf by adding the following lines: Section "Extensions" Option "Composite" "Disable" EndSection Logout and back in. Then perform the steps described in the original report. For me the application menu winds up on top of the zoomer window (i.e. and does not get magnified). If I first launch magnifier and then launch Orca, the menu fails to get magnified AND the zoomer blanks out to solid grey. This is on a single-head machine (laptop) with the software freshly and cleanly installed and no special hardware. :-) Carlos, do you mind giving this scenario a try on your hardware to see if you can reproduce it? Thanks in advance!!
This also happen here, and this is the expected result.
Is there something we can do to remedy it?
(In reply to comment #39) > Is there something we can do to remedy it? > The things discussed in bug #477683. I'm also opened to suggestions, but I don't mind anything more useful then messages or resize the zoom region.