GNOME Bugzilla – Bug 156699
constrain newly-posted windows to WORKAREA, if possible (a11y)
Last modified: 2005-11-19 17:15:27 UTC
[imported from sun internal bug tracking system] Select the logout option from the Launch Menu The logout dialogue appears but it is partly obscurred by the magnifier window. The dialogue cannot be dragged, meaning that the 'ok' button cannot be seen by the user. The dialogue should automatically go to where there is space for it (like the gdm standard greeter dialogue, for example). The 'ok' button can't be clicked either, so the user has to resort to keynav and a bit of guesswork to successfully log out. john.crawley@sun.com 10/21/04 13:38 GMT Real bug seems to be that magnifier isn't tracking the logout window... [bill.haneman@sun.com]
This is not a gnopernicus bug. The logout window _is_tarcked_ by the magnifier when the magnifier isn't covering it. The logout window should be made movable , just like the gdm window, and should reposition itself where there is space. Bill, please reasign this bug to the people that maintain the logout window.
yes, confirmed. The problem is with the placement of the logout window onscreen.
Currently windows which get placed at the center have a problem if the magnifier is placed any where but the top part of the screen. Should we have a policy of constraining these windows within all parts of the dock area around the screen when accessibility is on ? Also should this fix get into metacity or gtk ? Also see bug #161972.
Leena: I think the best fix for this problem would be to fix it for all centered windows, as you suggest. A fully-global fix might require changes to gtk+ and metacity, since a metacity fix would only affect managed windows (override-redirect windows centered via gtk+ would still not respect struts). However, since override-redirect windows are generally problematic, perhaps reducing their use (and making them managed-but-undecorated) would be best. The metacity fix for unmanaged windows would probably solve most issues.
Attaching a patch where, in case of a11y ON, the managed windows are constrained within the strut area. This fixes the problem of windows going behind the dock area (like, logout dialog appearing below magnifier). Also I am clueless how to go about for popups (unmanaged windows). Kindly comment.
Created attachment 37236 [details] [review] proposed patch for managed windows going behind docks
Thanks a lot Leena! I am not sure we want to make this behavior depend on meta_get_gnome_accessibility(). Unless there is strong objection to making this the default behavior (and I don't see how this would have a noticeable change in the behavior for most users). The more stuff that depends on the 'accessibility' gconf key, the more weird incompatibilities we are likely to introduce, the less exposure the codepaths will get, etc. Ask Havoc about whether this could be the default... As for unmanaged windows, the only way to fix this for them is to make a similar change to gtk+, in its code for centering windows. At the moment gtk+ doesn't track struts, so this might be a more involved fix (the unmanaged case). This bug affects lots of cases other than just Logout, as I am sure you know. Thanks again!
Attaching another patch where I am constraining the window within the strut/screen area only when it is shown for the first time. Once the window is placed, the user is free to move the window below the strut area (as it behaves currently). Using this approach the check for a11y will not be required. Kindly comment.
Created attachment 37330 [details] [review] proposed patch to constrain windows within strut area only when shown for the first time
*** Bug 167367 has been marked as a duplicate of this bug. ***
As far as managed windows go: 1) Struts aren't used in placement, only in constraints. 2) Users should be allowed to move windows so that they are partially hidden by windows with struts (e.g. moving part of the window below a bottom or side panel) 3) We don't distinguish between user actions and program actions in the constraints code Combine 1 through 3 and I think this is the cause of the bug. Leena's patch looks like an attempt to fix just one specific case of a much more general bug. I believe the fix I proposed in bug 136307 would fix the problem discussed here for managed windows as well. Unmanaged windows, of course, require individual attention... (Also, where do you actually want this bug? It seems to becoming a meta-bug, but it's product and description don't reflect that. It should probably either be resummarized and reassigned to metacity, or else the metacity portions should be split out into a separate bug...)
Thanks Elijah. I'd prefer to keep this bug in metacity, and update the summary accordingly. We should probably file a separate bug for unmanaged windows, in gtk+, where it's possible that gtk+ could impose strut constraints on centered windows. However it's not entirely clear to me how best to monitor something like WM_STRUTS outside of the WM. The patch I see in bug 136307 doesn't seem relevant to me...
That patch in bug 136307 isn't relevant (and should be rejected, IMO); start reading at comment 11 or so for the fix that I proposed which would handle half a dozen different constraints bugs. However, modifying constraints is somewhat problematic due to lots of various issues (as you may also note by Havoc's comments in that bug). I'm hoping I can come up with some solutions to make it not be such a problem (unless, of course, Rob or Havoc can think of something first), but we'll have to see...
Elijah: is there a good reason why Leena's patch should not be applied now? It solves a significant number of blocking problems for accessibility, we've got lots of internal dups (Sun bugs) around this, and get near-dups filed in community bugzilla too. Behaviorally it seems that Leena's patch does exactly what is required, i.e. constrain within struts on initial posting.
The only problem I can see with this patch is that the stricter constraints increases the number of cases where all constraints can't be satisfied; meaning that the number of cases in which we get unpredictable behavior is increased (we don't have a way to nicely relax certain constraints while enforcing others when we're unable to satisfy them all--bug 136307, comment 17). This would probably only be a problem for windows that are bigger than the screen size in one dimension (because we auto-maximize if the window is too big in both dimensions), but that kind of case should be rare so it seems sane to me. Of course, Havoc needs to be the one to review.
Havoc, could you review please? Posting windows outside WORKAREA seems wrong if it can be avoided, the constraint seems correct to me.
(Fixed on the constraints_experiments branch, FWIW)
[Cue Wizard of Oz music] Ding! Dong! The bug is dead! The wicked bug, The wicked bug, Ding! Dong! The wicked bug is dead...