more TODO: add documentation the most common usage would probably be with defaultLayout = Layout $ floatLayout (Layout $ LayoutSelection defaultLayouts) Bye. Karsten

On Thu, Oct 11, 2007 at 01:27:49AM +0200, Karsten Schoelzel wrote:

Hi,

this is to try out moving the floating to the level of layouts. This would make it possible to have different layout algorithms for the floating layer, including different decorations for windows there.

Yay!!!

At the moment it's possible to move windows with the mouse and keys. Additionally there is a hidden layer so windows can be hidden temporarily (this being the initial reason to investigate it: hide all floating windows for a moment)

TODO: - it's difficult to automagically move a window to the floating layer with a manageHook

Couldn't this be done with a simple sendMessage?

- moving windows between workspaces will *not* preserve the floating status

This issue shouldn't be too much of a problem, in my opinion. It'll be solved when floating is handled properly in the core. It could also be hacked by broadcasting the change to float status, but at the cost of having duplicate information about floating windows.

What do you think?

This is something I've wished I had time to do, and I'm glad you've gotten around to it! :) [...]

+type FloatInfo a = M.Map FloatState [(a, Rectangle)]

I think this would be much clearer and more bug-proof if you used data FloatInfo a = FloatInfo { hiddenWindows :: [(a, Rectangle)] , floatingWindows :: [(a, Rectangle)] , otherWindows :: [(a, Rectangle)] } This way you'll be using inherently total functions, and it should be faster code than a Data.Map, also.

+data RatRect = RatRect { rx :: Rational, ry :: Rational, rw :: Rational, rh :: Rational }

There's already a RationalRect defined elsewhere (but maybe with a different name), which I'd reuse, if you feel a need for such a beast.

+data FloatLayout l a = FloatLayout (FloatInfo a) (Layout a) + deriving ( Show, Read )

This would be better as data FloatLayout l a = FloatLayout (FloatInfo a) (l a) deriving ( Show, Read ) in the sense that it'd be easier to read and show. We should only use the Layout type when there's absolutely no way around it, which basically means when we've got to store a list of layouts.

+instance LayoutClass (FloatLayout (FloatInfo Window)) Window where

The instance constraint would then be: instance LayoutClass l Window => LayoutClass (FloatLayout l) Window where and the rest of your code should be unmodified by the elimination of the Layout data type (it'll of course be modified if you take my FloatInfo advice above). At another level, I think that this layout would benefit by being broken into three layouts: one layout to divide a window between two layouts, a second layout to implement a float-only layout, and finally, a "hidden" layout. This would give precisely the same functionality you've implemented, but would involve three much smaller layouts. Probably you'd want the float layout to include a simple function that behaves exactly as the one you defined (floatLayout), but by creating these three layouts you'd make it easy to reuse most of your code for other purposes (such as a decorated float layout, or one that preserves the size of float windows--here I'm assuming you've simply duplicated the behavior of the existing float layer). Just to be slightly more clear, I'm imagining the stacking layout as something like: data ChangeWindowLayer a = MoveToLayer String a deriving ( Show, Eq, Typeable ) data StackTwoLayouts ltop lbot a = StackTwoLayouts { windowsOnTop :: [a] , windowsOnBot :: [a] , layoutTop :: ltop a , layoutBot :: lbot a , topName :: String } deriving ( Show, Read ) So that this layout would have the reponsibility of dividing windows between the two layouts. The top one could be float while the bottom is tiled, or one of them could be hidden. Note also, that your monolithic approach isn't a bad idea, as in many ways any of these approaches are going to be prototypes. But the more modular approach I would guess would more easily morph into what we see replacing the current float layer. Eventually we'll want to have separate Stacks for the float and tiled layers, which ought to be done in the core, not in a layout. -- David Roundy Department of Physics Oregon State University

On Wednesday 10 October 2007 18:27:49 Karsten Schoelzel wrote:

Hi,

this is to try out moving the floating to the level of layouts. This would make it possible to have different layout algorithms for the floating layer, including different decorations for windows there.

At the moment it's possible to move windows with the mouse and keys. Additionally there is a hidden layer so windows can be hidden temporarily (this being the initial reason to investigate it: hide all floating windows for a moment)

TODO: - it's difficult to automagically move a window to the floating layer with a manageHook - moving windows between workspaces will *not* preserve the floating status

What do you think?

Let's postpone this until after 0.4.