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 105417 - Can't move window next to corner panel
Can't move window next to corner panel
Status: RESOLVED DUPLICATE of bug 86682
Product: metacity
Classification: Other
Component: general
2.4.x
Other Linux
: Normal normal
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
Depends on:
Blocks:
 
 
Reported: 2003-02-06 17:53 UTC by Michael Toomim
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.1/2.2


Attachments
The result of trying to vertically maximize xemacs (101.84 KB, image/png)
2003-02-06 17:54 UTC, Michael Toomim
Details

Description Michael Toomim 2003-02-06 17:53:39 UTC
Metacity won't allow a window to sit in the empty space to the right of a
corner panel.  Instead, it treats corner panels like edge panels, and acts
as if the panel takes up the entire edge of the screen.

For example, I have a screen with a corner panel in the upper left:

---------------------------
|_____|                   |
|                         |
|                         |
|                         |
|                         |
|                         |
|                         |
|                         |
|                         |
---------------------------

But I can't move a window into the free space in the upper-right.  The best
I can do is this:

---------------------------
|_____|       _________   |
|            |         |  |
|            |         |  |
|            |         |  |
|            |         |  |
|            |         |  |
|            |_________|  |
|                         |
|                         |
---------------------------

I'll attach a screenshot in a sec.
Comment 1 Michael Toomim 2003-02-06 17:54:36 UTC
Created attachment 14167 [details]
The result of trying to vertically maximize xemacs
Comment 2 Michael Toomim 2003-02-06 17:56:28 UTC
BTW, I added a GNOMEVER2.2 keyword, since this is for 2.2 and not 2.1
anymore. (Although it's been an issue since pre-2.0.)
Comment 3 Rob Adams 2003-02-13 20:52:30 UTC
I was thinking about this problem a bit, and I think that the solution
is that, in addition to work areas, we should calculate a set of
rectangular "move regions" that tile the workspace, so that we'd have
a move region for the area under the panel and another that reaches
all the way to the top of the screen where there is no panel.  I don't
think that finding the regions would be too tough, though it would
require a bit of thought.  For the purpose of computing move regions,
we would consider all windows that set a strut but ignore the strut
they set and use instead the actual geometry of the window that set
the strut.  We'd be able to cache them the way we do work areas so the
performance ought to be pretty good.  We would then add a
get_move_region_for_window function that we could call from the
constraints code.

What do you think of this solution, Havoc?
Comment 4 Havoc Pennington 2003-02-13 20:57:05 UTC
See http://bugzilla.gnome.org/show_bug.cgi?id=86682

In particular this comment:

I think there are several options, corner panels could either:

 - not set a strut and be below normal windows in stacking order

or 

 - set a partial-widget strut

or
 
 - something else

But you have to consider a) window titlebars should not end up
entirely underneath a panel, metacity should prevent that 
b) maximization should not stick the window under a panel
c) you should be able to move a window into empty space *next to* a
corner panel.

Step 1 I think is to pick one of the big picture options, then we'll 
figure out how to implement it.
Comment 5 Havoc Pennington 2003-02-25 22:57:21 UTC
I'm just going to dup this on bug 86682, since it's basically the same 
issue. We should put in a fix for both xinerama and corner panel cases.

*** This bug has been marked as a duplicate of 86682 ***