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 144126 - metacity maximizes windows to wrong size for large STRUTS values
metacity maximizes windows to wrong size for large STRUTS values
Status: RESOLVED FIXED
Product: metacity
Classification: Other
Component: EWMH specification
unspecified
Other All
: Normal major
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
AP1 constraints_experiments:targeted
: 149848 (view as bug list)
Depends on:
Blocks: 124690
 
 
Reported: 2004-06-10 23:01 UTC by bill.haneman
Modified: 2005-11-01 18:31 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
screenshot illustrating "over-maximized" window (164.85 KB, image/png)
2004-06-11 11:12 UTC, bill.haneman
  Details
corrected screenshot showing not-quite-correctly-maximized Mozilla (155.17 KB, image/png)
2004-06-11 11:31 UTC, bill.haneman
  Details
screenshot showing window with left border against the STRUT (170.32 KB, image/png)
2004-06-11 11:34 UTC, bill.haneman
  Details
proposed patch implementing Havoc's suggestion in Comment #9. (3.90 KB, patch)
2004-08-13 16:28 UTC, bill.haneman
none Details | Review
Final patch (4.24 KB, patch)
2004-08-15 15:27 UTC, Rob Adams
committed Details | Review
Fix to final patch above (831 bytes, patch)
2004-08-15 17:37 UTC, Rob Adams
committed Details | Review

Description bill.haneman 2004-06-10 23:01:20 UTC
Run an app like GOK, or better yet, gnome-mag's "magnifier" binary with the "-v"
option (from CVS HEAD, with the patch for bug 124690 applied).

Large WM_STRUT values are set (on the order of the screen width).  Although
Metacity verifies that the strut values are set correctly (by not allowing
windows to be dragged all the way under the magnifier window with the mouse), if
you maximize a window it's always maximized "too big", so that the right hand
side is cut off.  Similar problems seem to affect large top strut values.

This means that the magnifier's STRUT behavior doesn't really help the user
avoid having stuff placed under the magnifier's window.
Comment 1 bill.haneman 2004-06-10 23:03:31 UTC
Havoc, please check and see if I'm correct that this is a metacity bug (and not
something weird I'm doing); the fact that the drag bounds are matching the
magnifier window correctly makes me think I'm setting STRUTS correctly.  
Comment 2 Rob Adams 2004-06-10 23:12:57 UTC
I wrote the struts code for metacity.  If I remember correctly there's a sanity
check that prevents you from setting ridiculously big strut sizes, though I
don't recall exactly how that worked.  I think something like enforcing that
there's at least a box in the middle of at least a certain minimum size.

I'm not sure exactly what's wrong here; I don't have a HEAD build convenient to
test on.  Could you provide a screenshot or perhaps explain more precisely what
happens?
Comment 3 bill.haneman 2004-06-11 11:10:19 UTC
Rob:  maybe the sanity check needs to be revisited.  Especially if it's
something like "dont allow the window minus borders to get maximized to less
than half the screen width".  That's kind of what it looks like...

I can attach a screenshot of mozilla "maximized" alongside a magnifier which
takes up exactly half the screen width (RHS)... the mozilla window is wider than
half the screen, so the right hand 15% or so of the mozilla window is obscured
by the strut owner (magnifier window).
Comment 4 bill.haneman 2004-06-11 11:12:11 UTC
Created attachment 28588 [details]
screenshot illustrating "over-maximized" window
Comment 5 bill.haneman 2004-06-11 11:12:38 UTC
Rob: if you point me to the code I might be able to find the problem.
Comment 6 bill.haneman 2004-06-11 11:31:25 UTC
Created attachment 28591 [details]
corrected screenshot showing not-quite-correctly-maximized Mozilla

this screenshot was made after applying the STRUTS patch to gnome-mag; please
ignore the previous patch.
Comment 7 bill.haneman 2004-06-11 11:34:27 UTC
Created attachment 28592 [details]
screenshot showing window with left border against the STRUT

this attachment suggests that the STRUT value is correctly set, as there
is a window visible near the center of the screen which has been dragged to the
maximum allowed rightwards extent.
Comment 8 Rob Adams 2004-06-11 13:22:38 UTC
actually, come to think of it:  it's screen width/2-15 pixels is the maximum
strut size.  This was done to avoid a possibility of the constraint iteration
failing to find a fixed point.  This needs to be changed so that there's at
least a 30 pixel "window" somewhere on the screen that's not covered by a strut.
Comment 9 Havoc Pennington 2004-06-11 21:36:00 UTC
Something like this might fix:

gap = screen_width - left_strut - right_strut;
gap -= 15; /* require a gap of at least 15 */
if (gap < 0)
  {
     left_strut += gap / 2;
     right_strut += gap / 2;
  }

Comment 10 bill.haneman 2004-06-18 12:20:01 UTC
Rob: can you prepare a new patch for this?  Or are you waiting for me?
(I'll be pretty much away till post-GUADEC, but I'd really like to get this
resolved soon after.  Many thanks!)  Note that the gnome-mag patch is now in
CVS, so gnome-mag from HEAD can be used to test.  "magnifier -v -m"  should
highlight the problem.
Comment 11 bill.haneman 2004-08-11 18:51:08 UTC
Can we get a fix for this in GNOME 2.6.0 please?  It's making some GOK and
gnome-mag stuff pretty b0rked.  Or, Havoc, if you are waiting for me, just say
so and I will create the patch with your code snippet above.
Comment 12 Rob Adams 2004-08-11 18:58:48 UTC
Sorry I'd forgotten about this and I'm a bit swamped right now.  If you could
create a patch that'd be great.  Shouldn't be too hard I hope.

-Rob
Comment 13 Havoc Pennington 2004-08-11 23:14:06 UTC
Someone writing (and more importantly testing) a patch would be helpful, yes.
Comment 14 bill.haneman 2004-08-13 16:28:24 UTC
Created attachment 30518 [details] [review]
proposed patch implementing Havoc's suggestion in Comment #9.
Comment 15 bill.haneman 2004-08-13 16:30:00 UTC
This seems to solve most of the problems with gnome-mag and GOK regarding struts.
Comment 16 Havoc Pennington 2004-08-13 23:23:36 UTC
Comment on attachment 30518 [details] [review]
proposed patch implementing Havoc's suggestion in Comment #9.

Looks like you use screen->width and the left/right struts to compute gap for
the vertical

MIN( should be MIN (

looks good, thanks.
Comment 17 Rob Adams 2004-08-13 23:28:30 UTC
actually the gap between left and right struts does need to be at least 75, or
the constraints code handling the struts would run into problems, since the left
and right constraints would be mutually exclusive and there is no feasible
solution to the constraint satisfaction problem.  So change MIN_EMPTY back to 75.

Also, spaces, not tabs.
Comment 18 Rob Adams 2004-08-13 23:41:01 UTC
and also since you're doing gap/2 you'd need to set it to 76 so that the gap is
actually at least 75 and not 74, since 75/2 + 75/2 = 74.  Or maybe not; I can't
remember if (-75)/2 is -37 or -38.  Either way changing it to 76 would be better
I think.
Comment 19 Rob Adams 2004-08-15 15:27:22 UTC
Created attachment 30555 [details] [review]
Final patch

I've gone ahead and made those corrections to the patch and committed this
final version.	I'm going to go ahead and make a release now with this fix.
Comment 20 Havoc Pennington 2004-08-15 16:04:04 UTC
Comment on attachment 30555 [details] [review]
Final patch

It looks like this patch still uses the width struts to compute the gap for the
height calculation:

+	       gap = window->screen->width - struts[0] - struts[1];
+	       gap -= MIN_EMPTY;
+	       new_top.height = (int)struts[2] + MIN (0, gap/2);
Comment 21 Rob Adams 2004-08-15 16:33:11 UTC
Actually now that I think about it this patch doesn't remotely do what I was
initially thinking that it did.  All it does is look at a single set of struts
from a single window.  To ensure a feasible solution can be found by the
iteration, it would have to look at all the struts, which is a problem just as
difficult as the original constraint satisfaction problem in the first place.

One solution is to just keep the patch as it is (changing width to height, 0 to
2, and 1 to 3 as appropriate, and just allow the constraint iteration to get
confused and hit the paranoia limit if they have really insanely huge struts.

Or just have the magnifier not take up fully half the screen.
Comment 22 Rob Adams 2004-08-15 16:43:10 UTC
Note that in practice it would never be a problem if the constraint code gets
confused.  The result would be mildy unpredictable but consistent; i.e. it would
basically choose a constraint to violate and then allow that constraint to be
violated from then on.  But only if there was one set of struts on the left
overlapping with another on the right (or top/bottom).  The result in the user
interface I think would be really no worse than enforcing a struts gap, since
either way the window is underneath a panel-type window possibly irretreivably
(barring using the window list to choose Move and moving the window back).

So perhaps this patch is OK actually.
Comment 23 Rob Adams 2004-08-15 17:37:25 UTC
Created attachment 30560 [details] [review]
Fix to final patch above

This fixes the width/height problem.  I think I'm reasonably happy with this
now.
Comment 24 bill.haneman 2004-08-15 19:43:23 UTC
Rob, you said: "Or just have the magnifier not take up fully half the screen."
Not really an option, as the magnifier may need more than half the screen, etc.

But as you said, I suspect this final patch fixes the majority of cases.
Comment 25 bill.haneman 2004-08-16 09:48:54 UTC
I take it from the bug status and the attachment status that these last two
patches have not been applied?
Comment 26 Rob Adams 2004-08-16 15:30:17 UTC
no they have been, and they're in the 2.8.5 release made yesterday.

I left the bug open in case someone has a nice way to do this.
Comment 27 bill.haneman 2004-08-18 10:08:29 UTC
*** Bug 149848 has been marked as a duplicate of this bug. ***
Comment 28 Calum Benson 2004-10-21 16:45:35 UTC
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs.
 Filter on "SUN A11Y SPAM" to ignore.
Comment 29 Elijah Newren 2005-05-26 18:50:50 UTC
The patches have been committed so I'm marking them as such to get them off the
list of unreviewed patches
(http://bugzilla.gnome.org/reports/patch-report.cgi?product=metacity, which now
includes links to direct patches instead of just links to bugs)
Comment 30 bill.haneman 2005-11-01 17:30:30 UTC
Is there justification for keeping this bug open, insofar as the patches have
been in CVS for well over a year?  I've removed the 'accessibility' keyword for
now, to prevent this bug from continuing to show up in the open a11y bugs list,
but if you close this bug I'd appreciate it if you reinstated that keyword.  Thanks.
Comment 31 Rob Adams 2005-11-01 17:39:45 UTC
probably not.
Comment 32 Elijah Newren 2005-11-01 18:26:42 UTC
Actually, due to comment 21 and 22 there was a potential reason for leaving it
open.  However, I fixed this last issue on the constraints_experiments branch
anyway.