GNOME Bugzilla – Bug 467664
unmagnified area becomes too small to use
Last modified: 2007-10-10 20:12:26 UTC
Please describe the problem: If you accidentally set the magnified portion of the screen to be very large, you can end up with a very small unmagnified area. That area will be so small that you cannot see dialogs and you can not even fix your mistake with the magnification area. You're stuck!! Steps to reproduce: 1. Go into preferences 2. Make the magnified area very large Actual results: You can no longer see the bottom part of dialog boxes, including the Orca preferences. Expected results: It should not let you make the magnified area that large Does this happen every time? yes Other information: Sorry I'm not at the person's computer right now so I didn't include the versions, but they installed using using the standard Ubuntu Feisty CD and then did all the updates.
With the current versions available via CD and updates to Feisty, setting the magnified area to be very large could cause all sorts of oddities to occur. (For me, it would cause the entire screen to turn white not counting the cross hairs.). However, if I get the latest gnome-mag from svn trunk the problem goes away and I can make the magnified view as large as I want including occupying the full screen. Therefore, I *believe* that this bug is a bug in gnome-mag and one that has already been fixed. Steve, have you tried it with the latest gnome-mag from svn trunk (not the same as doing all the updates)?
You know, I can still reproduce this in OpenSolaris. And while Gutsy *used* to be fine, it looks like the latest changes to the xserver might be messing things up anew. I'll keep investigating the broader issue. Steve, I'm still interested in knowing if using the latest gnome-mag from svn trunk at least solves the problem you reported in Feisty. :-) Thanks!
(In reply to comment #2) > You know, I can still reproduce this in OpenSolaris. And while Gutsy *used* to > be fine, it looks like the latest changes to the xserver might be messing > things up anew. I'll keep investigating the broader issue. > > Steve, I'm still interested in knowing if using the latest gnome-mag from svn > trunk at least solves the problem you reported in Feisty. :-) Thanks! > I believe the problem is that the user's system is not enabled to support COMPOSITE. As a result, the magnifier and the unmagnified region compete for real estate. Joanie started working on a potential solution to this as part of bug 477683, but we decided it really was a separate problem. I'd surmise that a decent thing to do here might be to just never let the magnifier get larger than the source bounds.
Created attachment 96975 [details] [review] proposed patch The goal of this patch is merely to prevent the user from rendering his/her system unusable as the result of creating too large a target display in an environment that does not support it (i.e. composite is not present/enabled). If we are not "full screen capable"*, and if our source display is the same as our target display, and if the area we are trying to allocate to the target display is more than half of the total screen area, this patch sets the target display to occupy the right half of the screen. *N.B.: This patch relies upon gnome-mag telling us if we are "full screen capable". Carlos posted a patch to expose this information to us. (See bug 481009) At this moment, it is not checked in. I have tested this in the following environments: * Single-head Gutsy without Carlos' patch, composite enabled and composite disabled * Single-head Gutsy with Carlos' patch, composite enabled and composite disabled * Single-head OpenSolaris without Carlos' patch, composite enabled and composite disabled * Single-head OpenSolaris with Carlos' patch, composite enabled and composite disabled If Carlos' patch has not been applied, the logic Will added in bug 477683 still kicks in for the full-screen scenario. If composite is enabled, nothing changes. Otherwise, this patch seems to do the right thing. I still have to test this on the tri-head Solaris box. Due to some unforeseen side effects of my trying to figure out things like Xen and zpools and slicing, I, uh, need to do a wee bit of re-installation before attempting to build gnome-mag. ;-)
Will asked me in #orca what would happen if gnome-mag were already running and then Orca was launched. The answer is that it doesn't seem to matter. Test 1: Launch gnome-mag set to full screen then launch Orca with prefs set to full screen. - Without the patch, Will's "nothing to magnify" handling kicks in. - With the patch, we go to split screen as expected. Test 2: Launch gnome-mag set to half screen, horizontal split (so there's a top half and a bottom half). Then launch Orca with prefs set to full screen. - Without the patch, the magnified view occupies the top right corner only. - With the patch, the magnified view occupies the top right corner only. I found this behavior interesting and wonder if we want something else to occur instead. However, the patch is not changing what we do.
Okay, the tester apparently needs to drink more coffee and is addressing that at the moment. :-) On test 2, the weirdness only occurs with the patch. Without the patch, we kill magnification via the "nothing to magnify" handling. My bad and sorry for the confusion.
Created attachment 97014 [details] [review] take 2: handle test 2 and lots of comments :-) After discussing this further with Will in #orca we decided the following: 1. Regarding the "test 2" case: If we find ourselves trying to set the target display to something that a composite-less environment cannot support AND gnome-mag is already running we should respect the gnome-mag settings*. 2. The first version of my patch makes some assumptions which seem to be valid, but which also require reading my mind to understand the logic. ;-) Comments/documentation are my friend. :-) Sorry about that Will! *Just when I thought I was done.... The user could launch gnome-mag with -f (for full screen). gnome-mag will happily allow the user to do this even in a composite-less environment. I don't think this is all that unrealistic: The user, upon seeing Orca not allow them to use full screen magnification might try to force it to occur via gnome-mag. Therefore we should check to see if gnome-mag is running AND doing so in full screen mode before deciding whether or not to respect its target display. Still haven't tested this in the multi-head environment. It's on "the list" for this evening.
Created attachment 97018 [details] [review] take 3: don't set tdb if it's not going to change As Will observed in #orca: "No need to set tdb if we're going to make it the same." I thought we needed to set it to get the side effects/benefits Will mentioned in his comments in the code that follows. But the source display will already be set in this case, and testing indicates that setting tdb again is indeed unnecessary.
Created attachment 97022 [details] [review] take 4: get rid of unnecessary try/except's
Wonderful! Thanks. Please commit to trunk. :-) Feel free to close as FIXED, too. :-) Many :-). Even more :-).
Done. And there was much rejoicing. Yea. ;-)