Hi,
this is a brief description of the stuff I've been lately polluting
the mailing list with: the new decoration framework, this floating
layout and so on. I'm going to be long. Sorry, but I though that such
a digression could be useful for non/wannabe developers too.
So, it all started with "doLayout":
doLayout :: layout a -> Rectangle -> Stack a -> X ([(a, Rectangle)], Maybe (layout a))
take the screen geometry, an ordered stack of windows and produce a
list of those widows coupled with their generated geometry and,
possibly, an updated version of the layout - the way of doing the same
operation the *next* time.
Cool. This is what a window manager is all about, after all... But
soon we discovered that manipulating a list of windows and their
geometry, when you have the screen geometry and the ordered stack, may
be more fun. You have more information, after all.
This is how layout modifier started to appear. We stared seen layouts
doing:
(wrs,ml) <- doLayout l r s
and then you start playing with "wrs"...;)
When we switched to the class approach, David Roundy (my mentor when
it comes to type classes and stuff like that, even though I have the
feeling this has been a type adventure for him too...[1]), came up
with a nice solution: a layout (ModifiedLayout) which could take a
layout modifier and produce a ... modified layout!
The layout modifier must just be an instance of the LayoutModifier
class, with safe default method implementations. The basic method is
"redoLayout":
redoLayout :: m a -> Rectangle -> Stack a -> [(a, Rectangle)] -> X ([(a, Rectangle)], Maybe (m a))
As you see, this is like a "doLayout", but it gets the already
produced list of windows and their respective geometry. You have the
whole workspace populated of windows, and you can manipulate them!
So people started writing layout modifiers with this new framework.
But sometimes you can still see layout modifiers that are implemented
as layouts, that is to say, as member of the LayoutClass: Mirror,
Reflect, AvoidStruts just to mention a few. Why?
In most of the cases this happens just because of the need to modify
the rectangle or the stack to be passed to the "doLayout" with the
layout to be modified. Unfortunately the LayoutModifier class doesn't
(well, didn't) have something to deal with this situation.
So I created a new method class, "modifyLayout":
modifyLayout :: (LayoutClass l a) => m a -> l a -> Rectangle -> Stack a -> X ([(a, Rectangle)], Maybe (l a))
Now you can access the layout you are modifying and you can change the
rectangle and the stack. Then you have the generated list of windows
and geometries to start playing with. And, for free, you get all the
safe methods for correctly passing messages around, for dealing with
empty workspaces, and so on.
Now we can rewrite Reflect as a layout modifier:
Sun Jan 27 17:58:54 CET 2008 Andrea Rossato
* Reflect: reimplemented as a layout modifier (which makes it compatible with windowArranger and decoration)
M ./XMonad/Layout/Reflect.hs -15 +11
The same with AvoidStruts:
Sun Jan 27 15:43:01 CET 2008 Andrea Rossato
* ManageDocks: implement AvoidStruts as a layout modifier
M ./XMonad/Hooks/ManageDocks.hs -17 +11
You see? The code gets shorter! And the source of many bugs gets
eliminated!
I've also add the pure versions of the redoLayout and the message
handling methods: this way you can start manipulating the list of
(windows,geometries) purely... Don, do you like that possibility??
I'm sure you do!
;-)
Ok, so, what about this New Decoration Framework I've been talking
about?
After this small type class cleanup (well it did not occur in this
order actually, it's an adventure, after all...;), I started thinking
about a floating layout.
My first intent was to have a way of manipulating the windows'
geometry with the keyboard. This is how WindowArranger started.
The idea is to have a layer, a layout modifier, with a list of windows
whose geometry is managed by the underlying layout. But when a
window's geometry is modified by a message sent by the user, its
geometry will not be managed by that layout anymore, but only by the
WindowArranger modifier itself.
This is done with the ArrangedWindow type, with 2 constructors
"WR (a,Rectangle)"
for the windows managed by the underlying layout and
"AWR (a,Rectangle)"
for windows whose geometry has been modified by the user.
This list is processed with pure code only! And WindowArranger was the
fist pure layout modifier written.
I then decided to rewrite Tabbed too. Once someone asked to have tabs
with other layouts too. This is how I got the idea of transforming the
Tabbed layout in a Tabbed layout modifier.
Decorating a window only means creating a second window with a given
geometry and inserting it in the window list before the window we are
decorating. We need to keep track of all that, as we did with tabbed,
but that can be done with pure code only, as the WindowArranger
demonstrated. So I rewrote tabbed in a more general way, as an
instance of the LayoutModifier, and to be used with ModifiedLayout. I
didn't need to write anything to communicate with the X server. I just
used XMonad.Util.XUtils. I just needed to write the pure core to
process the state for keeping track of the decorations we created, and
the pure code for inserting them in the (window,geometry) list to be
passed to xmonad for actually refreshing the screen.
And I obviously copied my mentor's (David Roundy) approach. I created
a class, DecorationStyle, which basic method is "decorate":
decorate :: ds a -> Dimension -> Dimension -> Rectangle -> W.Stack a -> [(a,Rectangle)] -> (a,Rectangle) -> X (Maybe Rectangle)
a decoration style, the user configured width and height of the
decoration, the screen and the stack, the windows with their geometry,
and the specific window (and its geometry) you are creating the
decoration for. If you return Just a geometry, that geometry will be
used to create the decoration (with the user supplied configuration),
otherwise no decoration is created for that window.
Obviously there are pure methods here too.
This is XMonad.Layout.Decoration: a layout modifier that takes a
member of the DecorationStyle class and a shrinker to generate the
geometry of a decoration to be passed to xmonad..
So I then created some decoration styles: the default one
DefaultStyle, a tabbed like decoration (XMonad.Layout.Tabbed), a very
basic SimpleDecoration (Xmonad.LayoutSimpleDecoration), and what I was
told was the old dwm like decoration style (XMonad.Layou.DwmStyle).
Together with these decoration styles there are some simple
layoutModifier to apply those decoration to any layout. Remember that
Decoration is an instance of the LayoutModifier class:
- a simpleDeco modifier:
simpleDeco :: Shrinker s => s -> DeConfig SimpleDecoration a -> l a -> ModifiedLayout (Decoration SimpleDecoration s) l a
- a dwmStyle modifier:
dwmStyle :: (Eq a, Shrinker s) => s -> DeConfig DwmStyle a -> l a -> ModifiedLayout (Decoration DwmStyle s) l a
All these modifiers take a shrinker (the Shrinker class was one of
David's classes), and default configuration.
Then I rewritten the tabbed layout, as a layout modifier of the
XMonad.Layout.Simplest layout, a pure one line layout I wrote
specifically for tabbed:
- a tabbed layout:
tabDeco :: (Eq a, Shrinker s) => s -> DeConfig TabbedDecoration a -> ModifiedLayout (Decoration TabbedDecoration s) Simplest a
(there's also a compatibility layer with the old tabbed layout)
Then I added some other tools for helping combining this stuff, such
as ResizeSize, a layout modifier to modify the screen geometry.
That's it. Suppose you want to apply the tabbed decoration to circle
without shrinking each window:
decoration shrinkText defTabbedConfig (resizeVertical 20 Circle)
Do you want to add a simple decoration to all your layouts, with the
possibility of moving/resizing windows?
simpleDeco shrinkText defaultSimpleConfig (windowArrange $ layoutHook defaultConfig)
Obviously we can hide this combinations to the users, and provide them
with the final stuff.
Ok, so, where is the floating layout?
Well, it is just a side product of this stuff. Go read it:
http://gorgias.mine.nu/repos/xmonad-contrib/XMonad/Layout/SimpleFloat.hs
This is its type:
simpleFloat :: ModifiedLayout (Decoration SimpleDecoration DefaultShrinker) (ModifiedLayout WindowArranger SimpleFloat) a
SimpleFloat is a very simple layout (of the LayoutClass) which will
look at the newly created window's attributes and set its geometry
accordingly. The WindowArranger is set so that it will arrange all
windows after creation (which means the underlying layout will not
touch their geometry anymore). The WindowArranger lets you to
move/resize them. On top of that I added the a Decoration modifier
with a SimpleDecoration style and the default shrinker.
simpleFloat' will let you provide a custom configuration and a custom
shrinker.
To support this stuff the only required change to the core (Spencer
pushed it yesterday) is to add "emptyLayout" to the LayoutClass, so
that a layout is called even when the workspace is empty.
This has many beneficial effects. ShowWName, for instance, can show
the names of empty layouts too.
The mouse UI should go on to of Decoration. But there's one side
affect: a layout modifier *cannot* call "focus w". I still don't
exactly understand the whys and hows, but I'm sure it cannot.
I'm ready to push. My code is backward compatible. But there are those
layout modifier implemented as instances of the LayoutClass. If used
in the chain of layout modifiers I showed you above, if they do not
implement the "emptyLayout" method correctly they will prevent
Decoration from removing the last windows.
I'll wait some feedback before pushing.
Sorry I was so long, but I wrote quite some code.
Cheers,
Andrea
[1] Read here :) http://www.haskell.org/pipermail/xmonad/2007-September/002148.html
