GNOME Bugzilla – Bug 124533
Magnifier window over laps om other application.
Last modified: 2004-12-22 21:47:04 UTC
Description: Magnifier window has been moved to top of the screen. gedit & magnifier preference window are open. The menu bar & tool bar portion of the gedit application window has been overlapped by the magnifier window. Expectation: The application window get re-adjusted below the magnifier window.
There is no way that gnopernicus can move an opened application like gedit. The user can do that with the following steps: focus the application that you want to move (use ALT-TAB for this) and than select it for MOVE(Alt-F7); now with the mouse you can move the application in a way that it won't be overlapped by the magnifier window. Bill: do you see another option here?
Once you have focused the window, and pressed Alt-F7 to initiate the move operation, use the arrow keys to move the window 10 pixels at a time, Ctrl-arrow to move 1 pixel at a time, and Shift-arrow to move the window to the screen edge. Spacebar accepts the move, Esc cancels it. This is all documented in the GNOME Accessibility Guide: http://www.gnome.org/learn/access-guide/2.2/keynav-11.html#keynav-14 Note: there is either a documentation bug or a code bug with Shift-arrow; in my GNOME build it goes into corners rather than just the screen edge.
Adi: I don't see another option for already-existing windows. Note that the magnifier does identify itself as 'WM_TYPE_DOCK' which means that metacity should attempt not to put new windows over the magnifier. However the magnifier doesn't yet use the 'strut' mechanism to ask the window manager not to place windows in its area at all. We could use 'strut' just as 'gok' does when in 'DOCK' mode (and I think brlmonitor does as well). This would be useful for halfscreen magnification. Thanks for the suggestion, I will file an RFE for the magnifier. Can we think of a common situation in which the magnifier should -not- use 'strut' behavior, i.e. when the magnifier service should not ask the window manager to reserve its portion of the screen?
not a gnopernicus bug; duplicate of 124690. *** This bug has been marked as a duplicate of 124690 ***
Apologies for spam; adding a11y keyword so these bugs are picked up by our historical bug tracking script. Find/delete these emails by searching for "calum fixing a11y script".