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 167367 - Gnopernicus UI dialogs should respect STRUTS (esp. of magnifier window)
Gnopernicus UI dialogs should respect STRUTS (esp. of magnifier window)
Status: RESOLVED DUPLICATE of bug 156699
Product: metacity
Classification: Other
Component: EWMH specification
unspecified
Other All
: Normal normal
: ---
Assigned To: ps
ps
Depends on:
Blocks:
 
 
Reported: 2005-02-14 17:07 UTC by korn
Modified: 2005-02-14 20:45 UTC
See Also:
GNOME target: ---
GNOME version: 2.5/2.6



Description korn 2005-02-14 17:07:10 UTC
1. Launch Gnopernicus with vertical half-screen magnification, especially on a
lower resolution display (like 1024x768)
2. Go into all of the preferences dialogs, especially the Zoomer Options dialog.
3. Note that these dialog appears attempting to not overlap others (good), but
don't limit themselves to the unmagnified left-half of the display.  And
specifically the Zoomer Options dialog appears centered on the 1024x768 window,
and NOT centered on the unmagnified portion of the display.  [BUG]
Comment 1 bill.haneman 2005-02-14 17:26:39 UTC
this is a dup of the other STRUTS bugs.  Please don't file any more :-)
Comment 2 bill.haneman 2005-02-14 17:28:11 UTC

*** This bug has been marked as a duplicate of 156699 ***
Comment 3 korn 2005-02-14 17:57:14 UTC
Bill - to be clear then: the issue is in the GTK+ library that Gnopernicus' GUI
calls?
Comment 4 bill.haneman 2005-02-14 18:06:21 UTC
note that I assigned this to metacity.  The bug is in metacity's window
constraints code.  However, it probably could worked around in gnopernicus at
least partly by making sure that gnopernicus doesn't ask for windows to be
centered, and by explicitly placing them at a particular onscreen location.
I believe that the default metacity placement for 'normal' windows respects
struts correctly.
Perhaps there is something strange about the window type gnopernicus is
specifying for these windows (they do seem to be modal, which in my opinion they
should not be, anyway).
Comment 5 Elijah Newren 2005-02-14 19:40:38 UTC
See comment at end of bug 156699 that I just added...
Comment 6 korn 2005-02-14 19:46:34 UTC
Uh... if there is a reasonable Gnopernicus work-around, then this isn't a dup. :-)
Comment 7 bill.haneman 2005-02-14 20:17:43 UTC
that's purely conjecture, and the root problem is a dup.  The only issues are
whether we can/should implement a workaround independent of 156699.
Comment 8 Elijah Newren 2005-02-14 20:31:01 UTC
I wouldn't call the workaround reasonable.  All apps would have to monitor the
root window for struts (_NET_WORKAREA, IIRC) and make their windows avoid them
when possible.  Plus, if any new windows with struts are placed on the screen,
the applications would need to monitor for that and change the position of their
windows accordingly.  Ugly and nasty.  Metacity should do that for you.
Comment 9 bill.haneman 2005-02-14 20:38:38 UTC
Elijah:what's strange to me is that the gnopernicus dialogs sometimes seem to
get posted *entirely* underneath a strut (i.e. a wide strut from a magnifier
region).  I don't quite get this, because I thought other app windows were
initially posted so that the titlebar is onscreen, or at least >50% onscreen. 
Am I incorrect?
Comment 10 Elijah Newren 2005-02-14 20:45:18 UTC
There's a 75 pixels onscreen constraint, yes.  There could be a bug in the
current code that attempts to enforce that, and it's also possible that not all
constraints could be satisfied (one of the problems with the current code is
that if not all constraints are satisfied, it's difficult to determine which
ones are broken--applying constraint A, then constraint B, can mean that A is
violated if both can't be satisfied at the same time).