Snap

ooooh, snap (peas), girlThere has been some discussion on the last post about implementing functionality similar to Microsoft’s “Aero Snap”.  Your chronicler has never used Windows 7, but the idea is demonstrated in this video.  It appears to mean that:

  • when a window is dragged to the left or right of the screen, it is vertically maximised, and resized horizontally to half the screen width;
  • when a window is dragged to the top of the screen, it is maximised;
  • there are hints elsewhere that dragging to a corner minimises, but this is unconfirmed at present.

There are apparently several people who would like this implemented on the free desktop.

One option is to do it with an external tool.  This is the route taken by this tutorial by gotsanity.  It’s a simple matter of monitoring the root window for configure events; the link goes to a program which will demonstrate the general principle.  Making that program into a daemon which will solve this problem is only a matter of adding code to detect a window crossing screen borders, and some kind of payload for when one does.

The advantages of this approach are:

  • that it will work with any window manager, and
  • that we have previously said that almost anything which can be implemented externally should be, to preserve the lightweight nature of Metacity.

The disadvantages, however, are:

  • the need to keep a separate daemon running; this is a good deal more of a long-term problem than launching one-shot processes on a keystroke,
  • the difficulty in adding the grey box that tells you you’re about to trigger the effect (though this is certainly not impossible with such a method), and
  • the change in the moment of triggering from after you release the button to during; this is a side-effect of the modern ability to drag a window itself rather than a wireframe.  It would be hard to solve in any way that didn’t feel like a hack.  strokinder points out why this is problematic.

The ability could also be implemented within the window manager itself.  The advantages and disadvantages of this plan are mirror images of those of the other plan.  It may, however, be worth the added complexity.  Additionally, the loss of the portability inherent in using an external script may not matter: if this was implemented in Metacity itself, it would presumably be fairly easy to carry it over to Mutter, since in this area the systems differ little.  Porting to Compiz may be more of a difficulty.

If anyone with a little programming experience would like to volunteer to work on this, abundant help can be provided; otherwise we will see about dealing with it when the bug queue is reduced a little. Please follow GNOME bug 607694, where this issue is being discussed.

Photo © Darwin Bell, cc-by.

10 Comments

  1. Posted January 21, 2010 at 7:51 pm | Permalink

    While I agree with your general sentiment of “do random stuff in a daemon” I don’t think it is practically useful, nor correct.

    With this approach, metacity might be lightweight, but people will be running multiple daemons (likely written by different people in different languages/interpreters) in order to get the functionality they want.

    As the number of external daemons increase, at some level this defeats the point of a lightweight window manager…

  2. Posted January 21, 2010 at 7:55 pm | Permalink

    Generally, my idea was “do random stuff in an external process spawned on keypresses where possible”, rather than “do random stuff in a daemon”, which has its own problems as you mention; that’s why I said

    this is a good deal more of a long-term problem than launching one-shot processes on a keystroke

  3. mrmcq2u
    Posted January 21, 2010 at 8:03 pm | Permalink

    What about tabs in metacity. I thought I saw that idea blogged here at some point. Would be a great edition to have tabs handled by metacity rather than gtk. Any news on that? Is it being worked on?

  4. Posted January 21, 2010 at 8:39 pm | Permalink

    @mrmcq2u:

    Answered in a separate post: http://blogs.gnome.org/metacity/2010/01/21/tabs/

  5. anonim
    Posted January 21, 2010 at 8:45 pm | Permalink

    I would like to know how is gnome going to deal with new features introduced in metacity on mutter. If this gets done in metacity I guess many people would also like to have it in mutter.

    thanks

  6. Posted January 21, 2010 at 8:48 pm | Permalink

    @anonim

    The core of mutter is the same as metacity; it’s generally a simple matter of applying a patch.

  7. Posted January 21, 2010 at 9:41 pm | Permalink

    @Thomas: I think my point still stands, s/persistent memory usage/external tool startup time/

    Which is why I would love to see these things go into metacity rather than an external tool.

  8. Posted January 22, 2010 at 8:37 am | Permalink

    We already have our own Aero snap implementation in the upcoming compiz release. But thanks for offering to write code for us!

  9. Posted January 22, 2010 at 9:43 pm | Permalink

    Can I put myself down on a list, or start a list, of people who would hate this feature? :-/ I don’t know metacity well – I admit, I’m only really aware I’m using it because of how frequently Iceweasel crashes – but if it is at all possible to make it an opt-in thing, that would be nice. (I doubt it is, though.)

  10. Posted January 22, 2010 at 10:00 pm | Permalink

    @Katie

    Sure, I don’t intend to make anything like this work without a switch to turn it on. I imagine it would drive me up the wall, personally.

One Trackback

  1. By This Week In Metacity « ᛏᚦ on January 22, 2010 at 8:13 pm

    […] How can dragging to an edge cause effects (like Microsoft’s Aero Snap)? […]