* On Monday, October 12 2009, Jan Vornberger wrote:

On Mon, Oct 12, 2009 at 12:44:21AM +0200, Daniel Schoepe wrote:

...

On Mon, Oct 12, 2009 at 12:35:00AM +0200, Jan Vornberger wrote:

...

This is the decoration layout modifier I use for Bluetile's floating layout. I wrote it because SimpleDecoration wasn't simple enough. :-)

Mon Oct 12 00:05:12 CEST 2009 Jan Vornberger * NoFrillsDecoration - most basic version of decoration for windows

It seems you forgot to include a patch in your bundle:

darcs: Cannot apply this patch bundle, since we're missing: Sat Oct 3 18:14:33 CEST 2009 Jan Vornberger * Added focusMaster to BoringWindows

Ups, sorry. That's a patch I sent in earlier that hasn't been applied yet.

Attached is the NoFrillsDecoration patch again without this requirement.

Regards,

Jan

Applied, thanks.

Hey! On Mon, Oct 12, 2009 at 03:15:07AM -0400, Adam Vogt wrote:

* On Monday, October 12 2009, Jan Vornberger wrote:

...

This is the decoration layout modifier I use for Bluetile's floating layout. I wrote it because SimpleDecoration wasn't simple enough. :-)

Mon Oct 12 00:05:12 CEST 2009 Jan Vornberger * NoFrillsDecoration - most basic version of decoration for windows

PS: I since looked into the problem of patch bundles with unicode characters getting mangled when I use 'darcs send'. It is now a reported bug ( http://bugs.darcs.net/issue1644 ) and I'm using a workaround that will hopefully work for now.

When you reset the layout (M-S-space), all windows take a shorter size.

ex. with this ordering:

(named "F" $ borderResize $ noFrillsDeco shrinkText defaultTheme $ windowArrange simplestFloat)

The window shrinks every time you resize it horizontally too.

Could you document what the correct ordering of these pieces is (and/or just reference a XMonad.Config.Bluetile)?

In my recent patch bundle containing Bluetile's floating layout, I also now reference a typical usage example for BorderResize. I hope this clears this up a little bit. I never really tested it with simplestFloat much. The problems you observed are probably not avoidable, because of the way simplestFloat works. It makes calls with xlib to figure out the sizes of the windows. If decoration comes into play, the windows shrink a little bit to make room for the decoration. Those shrunken windows are then again the bases for simplestFloat if you do a reset etc., which results in them shrinking every time. This problem was one of the reasons why I decided to create the PositionStore, because relying on those xlib calls to provide size information just doesn't seem like a very reliable way. So the BorderResize documentation now mentions, that it has only been tested with PositionStoreFloat. Regards! Jan