* On Wednesday, September 30 2009, Spencer Janssen wrote:

On Wed, Sep 30, 2009 at 02:15:46PM +0200, Jan Vornberger wrote:

...

Wed Sep 30 14:11:05 CEST 2009 Jan Vornberger * A ResizableTile-like layout that can be resized using the mouse. All separations between windows can be dragged to modify the layout. Keyboard commands can also be used to achieve the same effect.

How else does this differ from ResizableTile? Can we merge the two? Less code is always better.

Cheers, Spencer Janssen

I think the ResizableTile module should just be replaced by this one, since it provides a superset of the ResizableTile functionality. Listening for mouse clicks might have some kind of performance issues, but we could make those things optional? I've pushed this regardless, since it was pretty tricky to get this one to apply since the patch context was mangled: ] darcs: bug in get_extra commuting patches: ] First patch is: ] Mon Jul 14 11:36:01 EDT 2008 Marco Túlio Gontijo e Silva ] ] * XMonad.Actions.Plane.planeKeys: function to make easier to configure ] Second patch is: ] Wed Jun 17 20:37:29 EDT 2009 Adam Vogt ] * Correct many typos in the documentation, consistent US spellingg The patch contained T??lio, but after correcting it to Túlio in the patch, the bug disappeared.

On Fri, Oct 02, 2009 at 01:39:06AM +0200, Jan Vornberger wrote:

On Wed, Sep 30, 2009 at 01:10:46PM -0400, Adam Vogt wrote:

...

* On Wednesday, September 30 2009, Spencer Janssen wrote:

...

On Wed, Sep 30, 2009 at 02:15:46PM +0200, Jan Vornberger wrote:

...

Wed Sep 30 14:11:05 CEST 2009 Jan Vornberger * A ResizableTile-like layout that can be resized using the mouse. All separations between windows can be dragged to modify the layout. Keyboard commands can also be used to achieve the same effect.

How else does this differ from ResizableTile? Can we merge the two? Less code is always better.

I think the ResizableTile module should just be replaced by this one, since it provides a superset of the ResizableTile functionality.

Listening for mouse clicks might have some kind of performance issues, but we could make those things optional?

It probably has some kind of performance impact, as input windows have to be created, I agree.

The performance impact should be marginal. I think we can disregard this as a reason not to replace ResizableTile.

There is another subtle difference in the way 'slave' windows are handled: When you have one master window and three slave windows open in ResizableTile, the slave windows will get about 1/3 of the height each. The way those sizes are calculated is somewhat tricky though, because you can resize all those slave windows individually. Modifying one slave window will usually also affect all the others.

I found that to be to hard to work with when I wanted to implement the option to change the boundaries with the mouse. So in MouseResizableTile the sizes are calculated in such a way, that modifying one boundary will only affect the two adjacent windows. That way it's easier to calculate how far you can drag the boundary (as the min and max value doesn't change while you drag - as it would if I would use the calculation scheme of ResizableTile). With three slave windows open, you will get 1/2, 1/4 and 1/4 by default. You can of course still resize them to 1/3, 1/3, 1/3, it's just that the default is different and modifying boundaries will behave slightly different. People who are used to ResizableTile would probably notice that quickly.

I don't find these changes to be objectionable, but I don't use ResizableTile. Can we have some current ResizableTile users try this module out? If we don't get any complaints before the next release, let's just replace the old module with this new one. Cheers, Spencer Janssen

Excerpts from Spencer Janssen's message of Thu Oct 01 21:05:03 -0600 2009:

I don't find these changes to be objectionable, but I don't use ResizableTile. Can we have some current ResizableTile users try this module out? If we don't get any complaints before the next release, let's just replace the old module with this new one.

The resizing behavior seems okay to me, however, ResizableTall allows configuring exact window dimension layouts in a way that MouseResizableTile doesn't currently. Mosaic sort of fills the need, but haven't quite gotten it to work as nicely with say: two 90 column masters, one m lines tall, the other n lines, with three slave windows at m/2 m/2 and n lines tall. With resizable tile this sort of thing is pretty easy to set up. With MouseResizableTile it would need to be arranged manually, can't currently be set with parameters. It may be that GridVariants or some other layout can provide for such instead; sorry haven't researched it yet. I've actually moved to an auto incrementing tall with m/n split as main layout anyway, so I'd not object much to the proposed deletion of ResizableTile even if means to parameterize MouseResizableTile aren't provided. Deleting DragPane (or redefining it as a compatibility module to be removed on 1.0 release) seems possible, too, although the lack of configurability issue applies there too: import XMonad.Layout.LimitWindows limitWindows 2 mouseResizableTile -- DragPane Horizontal 0.03 0.5 limitWindows 2 mouseResizableTileMirrored -- DragPane Vertical 0.03 0.5 -- wmw