GNOME Bugzilla – Bug 321683
gnopernicus magnifier bounds sometimes set incorrectly.
Last modified: 2006-02-08 09:50:22 UTC
Version details: 0.11.1 Distribution/Version: snv_28 1.Launch one application, say, mozilla, evolution, gedit and so on. 2.Launch gnopernicus-magnifier. Do not change any settings of magnifier preferences. Expected result: Gnopernicus-magnifier should work correctly. Actual result: Gnopernicus-magnifier sometimes works incorrectly, it will only magnify part of the screen or push the source screen to a very narrow screen. I'd like to attach the screenshot below.
Created attachment 54852 [details] Screen Shot
It may happen 2-4 times among 10.
Since you don't change any of the magnifier settings in gnopernicus, I'll assume that you are not using 2 frame buffers and you are magnifiing the same screen on which the magnifier window is shown. In this case, I don't think this is a gnopernicus bug. Most gtk windows are resizing themselves so they won't get underneath the magnifier. This is what I think happens with evolution and gedit. This resizing of the windows is done by something called STRUTS and it's not controlled by gnopernicus. For example. If you have a gedit window maximized, when you start gnopernicus + magnifier, if the magnifier window is on the same screen as the gedit window, the gedit window should resize itself so it won't overlapp with the magnifier window. The strange thing is that this should happen every time, not just 2 - 4 out of 10 times.
You can see the screen shot, the magnifiered screen turned to one pixel line. This is the right bug I mentioned here.
Tim, please use a more specific bug summary next time. And please do not use the bracketed terms like [magnifier], this is unnecessary. Thanks. Dragan, the problem here seems to be in the race conditions involved when the magnifier tries to move its left/right/top/bottom bounds independently. gnopernicus really should be setting these all in one go, as the API for gnome-mag requires all four bounds at once. Setting them one at a time can cause the problem Tim reports, and it's not really a gnome-mag bug in my opinion (because it's getting invalid/silly bounds requests soemtimes, due to the race condition).
Sorry, didn't see the magnifier window in the screen-shot before. I needed to zoom -in. Bill, this is not easy to fix in the current implementation of gnopernicus. Maybe it would be easyer to fix this in gnome-mag. Tim, please try the pacth from bug 320640. That patch could filter some non-neccessary "set" commands for the magnifier when it starts.
I don't think this is feasible to fix in gnome-mag; I have looked at the issue many times before.
Another point for this bug is that the bounds are changed in gnopernicus magnifier when bug does appear. The user then needs to go into gnopernicus magnifier preferences and change the values of the zoomer placement. I believe this bug relates to: http://bugzilla.gnome.org/show_bug.cgi?id=320640 but I may be mistaken.
Tim please try the new gnopernicus from CVS HEAD. It contains the patch for bug #320640. It might fix the problem.
Created attachment 58505 [details] [review] proposed patch this patch prevents gnopernicus to send a set of coordinates for zoomer placement for every coordinate changed (a set for top, a set for left etc).
Patch looks like the right approach. I haven't had change to test it yet however.
I agree with Bill, this patch looks good (though it took a while to be certain; it would be helpful if the diffs contained more context!). Remus - what tests have you guys run?
Created attachment 58868 [details] [review] proposed patch Added more context to diff so that the functions name in which modifications are made to be obvious.
Thanks, the patch *looks* even better now - much easier to quickly review. If testing shows the problem fixed, please apply.
Comment on attachment 58505 [details] [review] proposed patch patch applied to cvs head.