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 165454 - "no-overlap" mode
"no-overlap" mode
Status: RESOLVED DUPLICATE of bug 81704
Product: metacity
Classification: Other
Component: general
2.8.x
Other All
: Normal enhancement
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
Depends on:
Blocks:
 
 
Reported: 2005-01-27 21:38 UTC by Reed Hedges
Modified: 2005-01-27 22:41 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description Reed Hedges 2005-01-27 21:38:27 UTC
This might be an unusual request, but it's something I've desired from a window
manager for a long time, based on the way I tend to work with windows.

It's related to another feature request I just made as well.

It would be convenient to have a mode in which either (a) all visible windows,
or (b) all visible windows from the same application (group), could never
overlap due to the user dragging them by their title bar.  For example, dragging
one window on top of another window, the first window would stop moving when
their edges touched, until you had continued to drag the mouse halfway accross
the second window, in which case the windows would swap positions and you could
continue dragging the first window.

Does this make sense?

I know this is a slightly exotic request and may not fit with the simplicity of
function philosophy of metacity, but I feel that it would be a very usable and
productive window management method, it would certainly help me in working with
the computer and I think many other people as well.

Thanks

Reed
Comment 1 Elijah Newren 2005-01-27 21:44:47 UTC
I believe that having edge resistance would do well enough to make it easy for
the user to ensure that windows don't overlap but are as close as possible to
each other.  Right now, I agree that this is a pain, but I'm sure edge
resistance will make it nice.  :)

*** This bug has been marked as a duplicate of 81704 ***
Comment 2 Reed Hedges 2005-01-27 22:17:33 UTC
Thanks for looking at my request, Elijah!  

This is different from edge resistance because new windows would also attempt to
avoid overlap, and instead of the windows overlapping when the resistance
threshold is overcome, the windows would rearrange. Maybe I'm being unclear, or
maybe this requires a completely new window manager :)   

Finally, the ideal feature implementation would have a mechanism for grouping
windows such that group co-members could not overlap but, nonmembers could.

Again, I don't know how possible this is, it's really just a wish list item,
though I may try hacking out a rough patch to demonstrate if I can.  Edge
resistance might be a fine substitute.

Thanks again!

Reed
Comment 3 Elijah Newren 2005-01-27 22:41:05 UTC
Yes, I know the request is different, but:
  1) I think it's a niche use case that would confuse most people
  2) Window grouping is inherently buggy (check out all the bugs on libwnck
     grouping), and I don't think it could be usable as part of such a feature
  3) I believe it provides very little benefit beyond what edge-resistance
     would provide
  4) There are nasty edge cases to worry about when there are too many windows
     on the screen

Lots of coding effort, possibility for lots of bugs, and I believe very little
payoff compared to a WM that had edge-resistance already.  (I agree the benefits
would be large compared to Metacity as it currently stands, but I don't think it
would be much of an advantage at all relative to when we have edge-resistance
implemented)

However, there is the possibility that I'm not envisioning the same use case as
you.  I'm imagining that you want a way to be able to make your windows line up
next to each other, without overlap or empty space, so as to be able to maximize
the use of your screen space and minimize the distance your mouse has to travel.
 Is there a different reason you want this?