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 322070 - Constraints don't always apply correctly for partial struts
Constraints don't always apply correctly for partial struts
Status: RESOLVED FIXED
Product: metacity
Classification: Other
Component: general
2.13.x
Other Linux
: Normal normal
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
Depends on:
Blocks: 155458
 
 
Reported: 2005-11-21 20:21 UTC by Rob Adams
Modified: 2006-01-10 04:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
First screenshot -- not much window visible (1.49 KB, image/png)
2005-11-21 20:23 UTC, Rob Adams
  Details
second screenshot -- nonoptimal solution to constraints (3.63 KB, image/png)
2005-11-21 20:23 UTC, Rob Adams
  Details
Fix the allowed-to-only-have-on-pixel-thickness onscreen issue (7.94 KB, patch)
2006-01-09 20:28 UTC, Elijah Newren
committed Details | Review

Description Rob Adams 2005-11-21 20:21:44 UTC
I can pretty easily get windows almost completely occluded by panels, up to and
including leaving just one pixel width visible.

Also, it doesn't seem to find the closest feasible region correctly.  Consider
the following screenshots (to be attached).

In the first screenshot, a right panel and a bottom panel combine to leave just
one row of pixel visible on the window.  In the second screenshot I move the
right panel down one pixel to completely occlude the window, which causes it to
be moved up, rather then left which is a much better solution.
Comment 1 Rob Adams 2005-11-21 20:23:05 UTC
Created attachment 55048 [details]
First screenshot -- not much window visible
Comment 2 Rob Adams 2005-11-21 20:23:40 UTC
Created attachment 55049 [details]
second screenshot -- nonoptimal solution to constraints
Comment 3 Rob Adams 2005-11-21 21:57:12 UTC
maybe we should simply cull out any feasible rectangles which are either
narrower or wider than some threshold?  That would presumably fix the first
issue, though not the second.
Comment 4 Rob Adams 2005-11-21 21:57:37 UTC
narrower or *shorter* than some threshold.
Comment 5 Elijah Newren 2005-11-21 22:08:41 UTC
Yeah, the basic way the algorithm works is to first find those maximal/spanning
rectangles that I was taking about.  For the first issue you mention, one of the
rectangles would be screen_width x 1 in size.  The keep-partially-onscreen
constraint is then defined in terms of extending the all maximal/spanning
rectangles in each of the directions corresponding to how much it can be
offscreen  for that direction.  It just turns out that your 1 pixel height was a
case where the window was offscreen in both directions and since the window is
allowed more than halfway off the screen in each direction it seemed perfectly
fine to the algorithm.

We could cut out small rectangles like you say or maybe require a certain
percentage be on the screen.  Either sounds fine.

I wasn't able to duplicate the second issue; I tried making a setup like yours
but the window always got shoved to the left.  Could you specify the dimensions
of each of the panel and the window and I'll see if maybe that helps me reproduce?
Comment 6 Elijah Newren 2006-01-09 20:28:33 UTC
Created attachment 57061 [details] [review]
Fix the allowed-to-only-have-on-pixel-thickness onscreen issue

(I still can't duplicate the second issue and will need a verbose debugging log to do anything with it)
Comment 7 Havoc Pennington 2006-01-10 03:00:48 UTC
I don't have anything intelligent to say on this one, if you guys think it looks good then go for it.
Comment 8 Elijah Newren 2006-01-10 04:58:37 UTC
Committed.

Since the second issue was different, Rob, please open a separate bug if you can still duplicate and provide a verbose debugging log.