
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. 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'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.
Hm, that's unfortunate. :-/ Looks like a unicode problem. My locale is set to 'de_DE.UTF-8' - but indeed, the patch file that 'darcs send' created seems to contain only 'T??lio'. Thx for fixing it - I will look into how I can prevent that from happening again. Regards, Jan