After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 156699 - constrain newly-posted windows to WORKAREA, if possible (a11y)
constrain newly-posted windows to WORKAREA, if possible (a11y)
Status: RESOLVED FIXED
Product: metacity
Classification: Other
Component: general
unspecified
Other All
: High major
: 2.10.x
Assigned To: Metacity maintainers list
Metacity maintainers list
AP1 constraints_experiments:targeted
: 167367 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-10-28 12:13 UTC by bill.haneman
Modified: 2005-11-19 17:15 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed patch for managed windows going behind docks (3.53 KB, patch)
2005-02-09 13:13 UTC, Leena Gunda
none Details | Review
proposed patch to constrain windows within strut area only when shown for the first time (3.25 KB, patch)
2005-02-11 10:23 UTC, Leena Gunda
none Details | Review

Description bill.haneman 2004-10-28 12:13:20 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]
Comment 1 Dragan Sarbut 2004-10-28 13:00:45 UTC
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.
Comment 2 bill.haneman 2004-11-05 14:52:02 UTC
yes, confirmed.  The problem is with the placement of the logout window onscreen.
Comment 3 Leena Gunda 2005-02-01 15:18:13 UTC
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.
Comment 4 Leena Gunda 2005-02-01 15:20:59 UTC
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.
Comment 5 bill.haneman 2005-02-01 15:45:08 UTC
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.
Comment 6 Leena Gunda 2005-02-09 13:10:57 UTC
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.
Comment 7 Leena Gunda 2005-02-09 13:13:08 UTC
Created attachment 37236 [details] [review]
proposed patch for managed windows going behind docks
Comment 8 bill.haneman 2005-02-09 13:33:10 UTC
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!
Comment 9 Leena Gunda 2005-02-11 10:21:28 UTC
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.
Comment 10 Leena Gunda 2005-02-11 10:23:49 UTC
Created attachment 37330 [details] [review]
proposed patch to constrain windows within strut area only when shown for the first time
Comment 11 bill.haneman 2005-02-14 17:28:12 UTC
*** Bug 167367 has been marked as a duplicate of this bug. ***
Comment 12 Elijah Newren 2005-02-14 19:40:27 UTC
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...)
Comment 13 bill.haneman 2005-02-14 20:16:34 UTC
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...
Comment 14 Elijah Newren 2005-02-14 20:24:00 UTC
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...
Comment 15 bill.haneman 2005-03-03 12:00:59 UTC
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.
Comment 16 Elijah Newren 2005-03-03 16:32:50 UTC
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.
Comment 17 bill.haneman 2005-08-28 23:22:56 UTC
Havoc, could you review please?  Posting windows outside WORKAREA seems wrong if
it can be avoided, the constraint seems correct to me.
Comment 18 Elijah Newren 2005-11-01 18:28:51 UTC
(Fixed on the constraints_experiments branch, FWIW)
Comment 19 Elijah Newren 2005-11-19 17:15:27 UTC
[Cue Wizard of Oz music]

Ding! Dong!  The bug is dead!
The wicked bug,
The wicked bug,
Ding! Dong!  The wicked bug is dead...