
Hi all, I've done a bit of xmonad hacking at home recently (where I no longer have an internet connection), and thought I'd mention what I've done, and see what other developers think. Basically, I've been hacking on the dragging code, which seems pretty ugly to me. I added a "dragging" datum of type Maybe (Position -> Position -> X (), X ()) which is usually Nothing, but if we're in the process of dragging something, the first is a callback function for motion events, and the second is a callback for the button release event (which is assumed to terminate the dragging). The result is that moving and resizing windows doesn't interrupt xmonad's regular event loop, and means (among other things) that tabs get redrawn while moving float windows (for instance if the float window gets moved over the tab like an eraser). This is a bugfix, but not of a very relevant bug. The real motivation is to allow dragging interactions as a first-class UI citizen. In particular, I would like to have a draggable version of TwoPane, which would send special resize Messages as the user drags the border between the two panes. This will be particularly helpful with Combo layouts, since I haven't found a useful way to make the keyboard bindings for resizing panes work with Combo (no useful way to tell which Layout you're talking to). But it's also nice for just a vanilla TwoPane (except I'm making a new Layout, of course, so you happy TwoPane users won't be bothered), since the mouse has considerably higher bandwidth than the keyboard (i.e. there isn't the tradeoff between a high delta so you can quickly resize and a low delta so you can accurately resize). It'd also be handy for things like a XMonadContrib floating layout with title bars on the windows (which would hopefully eventually be a candidate for replacing the default float layout via Config modification). Anyhow, since this is a change in a pretty core bit of xmonad, I thought I should mention it, even though I can't yet send in patches. Suggestions will be welcome (or someone who wants to reimplement this themselves... since I won't be able to read any suggestions at home...). I'll be back into the world of home internet connectivity after I move in a couple of weeks, so that's when you can expect to get patches (I could bring my laptop into work, but I'm really busy just now...). -- David Roundy Department of Physics Oregon State University

On Mon, Aug 06, 2007 at 05:17:05PM -0700, David Roundy wrote:
The result is that moving and resizing windows doesn't interrupt xmonad's regular event loop, and means (among other things) that tabs get redrawn while moving float windows (for instance if the float window gets moved over the tab like an eraser). This is a bugfix, but not of a very relevant bug.
This is very useful indeed. (I'll add that I would like to have a hook that can be set for events that are not handled by the main event loop too.)
It'd also be handy for things like a XMonadContrib floating layout with title bars on the windows (which would hopefully eventually be a candidate for replacing the default float layout via Config modification).
This is something I would like to see implemented. I thought about starting to hack such a layout but now I think I'll be waiting for your preliminary work to be done and then I'll jump in to help. Thanks, Andrea

This would be quite good.
Have you seen my FlexibleManipulate contrib? (I suppose it might be
rather hard, when you don't have internet). It allows grabbing
locations on floating windows to drag+resize them. It's also rather
crazy, as in the default, 'linear' mode (specified by a passed in
distribution function), the closer you are to the center, the more you
are positioning, the closer to the edge, the more you are resizing.
The discrete mode is much more rational and probably better (splits
each axis into thirds, so there's 9 regions per window).
Other than much more natural window manipulation, benefits include
only requiring one mouse button and not warping the mouse to a corner.
Perhaps something like FlexibleManipulate's discrete mode could be
used for resizing in xmonad.
-Michael Sloan
On 8/6/07, David Roundy
Hi all,
I've done a bit of xmonad hacking at home recently (where I no longer have an internet connection), and thought I'd mention what I've done, and see what other developers think.
Basically, I've been hacking on the dragging code, which seems pretty ugly to me. I added a "dragging" datum of type
Maybe (Position -> Position -> X (), X ())
which is usually Nothing, but if we're in the process of dragging something, the first is a callback function for motion events, and the second is a callback for the button release event (which is assumed to terminate the dragging).
The result is that moving and resizing windows doesn't interrupt xmonad's regular event loop, and means (among other things) that tabs get redrawn while moving float windows (for instance if the float window gets moved over the tab like an eraser). This is a bugfix, but not of a very relevant bug.
The real motivation is to allow dragging interactions as a first-class UI citizen. In particular, I would like to have a draggable version of TwoPane, which would send special resize Messages as the user drags the border between the two panes. This will be particularly helpful with Combo layouts, since I haven't found a useful way to make the keyboard bindings for resizing panes work with Combo (no useful way to tell which Layout you're talking to). But it's also nice for just a vanilla TwoPane (except I'm making a new Layout, of course, so you happy TwoPane users won't be bothered), since the mouse has considerably higher bandwidth than the keyboard (i.e. there isn't the tradeoff between a high delta so you can quickly resize and a low delta so you can accurately resize).
It'd also be handy for things like a XMonadContrib floating layout with title bars on the windows (which would hopefully eventually be a candidate for replacing the default float layout via Config modification).
Anyhow, since this is a change in a pretty core bit of xmonad, I thought I should mention it, even though I can't yet send in patches. Suggestions will be welcome (or someone who wants to reimplement this themselves... since I won't be able to read any suggestions at home...). I'll be back into the world of home internet connectivity after I move in a couple of weeks, so that's when you can expect to get patches (I could bring my laptop into work, but I'm really busy just now...). -- David Roundy Department of Physics Oregon State University _______________________________________________ Xmonad mailing list Xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
participants (3)
-
Andrea Rossato
-
David Roundy
-
mgsloan