[xmonad] some cleanup

Andrea Rossato mailing_list at istitutocolli.org
Fri Feb 1 22:00:40 EST 2008

On Fri, Feb 01, 2008 at 02:51:33AM -0600, Spencer Janssen wrote:
>  - Run 'decorate' even on windows that aren't returned by doLayout (perhaps use
>    Maybe Rectangle as an argument, where Nothing signifies the window isn't
>    visible)

why should I decorate those windows and then mark them as non visible?
How can I know which window is visible in, say, a decorated circle
layout, or in a floating layout? All windows maybe decorated, and it
is only by inspecting its geometry (can be done) and comparing it with
the geometry of the list of all windows (decorate can do that too),
that you can have an idea of what could be visible.

Instead, it is decorate that may want or not to want decorate a
window, and indeed it returns a Maybe rectangle (the pure version).
Think about the DwmStyle... When a layout produces a list of windows,
decorations will look the stack and will not decorate that window
returning a Nothing.

>  - Allow 'decorate' to return a list of decorations, rather than a single
>    decoration.

I don't get this. decorate is run to each member of the (window,
rectangle) list produced by a layout (resync in the instance, - resync
is not pure to let to let decorate return X (Mayb Rectangle), and
operate in the X monad.

> I haven't been able to divine the logic behind the code to make either
> modification myself, but I might be able to with a bit of documentation tossed
> in there :)
> I'm inclined to leave the base layout as Full, even though that is slightly
> broken at the moment.  Thus are the perils of running software-in-development.

this is the pipe line. Every layout may (should be possible for it to) through;:

1. doLayout is called to some layout and a list [(w,r)] is produced;

2. arranger (pure layout modifier) which keeps track of geometries: 

data ArrangedWindow a = WR   (a, Rectangle) -- original geometries produced by the underlying layout
                      | AWR  (a, Rectangle) -- geometry modified by a sendMessage

The modifier (instance of LayoutModifier), with only a pure implementation:
type ArrangeAll = Bool
data WindowArranger a = WA Bool ArrangeAll [ArrangedWindow a] deriving (Read, Show)

The Bool to toggle it off and on with a sendmessage. ArrangeAll for
the floating layout.

3. Decorator: process the list and according to the DecorationStyle
   decide if and how decorate each window of the list. Choice is
   almost pure but in the X for more expressiveness of the types.

3a: decorate, the main method of the DecorationStyle is: 
    decorate :: ds a 
		   -> Dimension -- user defaults, may be overwritten (decoration too small) 
		   -> Dimension -- user defaults, may be overwritten (decoration too small) 
		   -> Rectangle -> W.Stack a -> [(a,Rectangle)] -> (a,Rectangle) -> X (Maybe Rectangle) 

    takes everything and, specifically the window and the rectangle to
    decorate (and run in resync, which could be pure, but I did it
    impure for increasing the power of decorate in terms of windows
    choice - windowAttributes?). The task of resync is to keep
    synchronized the (w,r) list with the decoration list (and
    geometry) - its State component.

3b: finally insert_dwr will fold the list of windows and (Maybe)
decorations and will place them in front of the window they were
created for.

4: then you start applying post decoration modifier, like
WindowRemover (if you want remove window).

5. everything gets to restackWindos d list

6. Decoration keeps track of every decoration and will remove them when
   requested, or by an empty layout.

My working proposal, as I reported in the abused tracker, the *really*
ugly one, is to return the first window of the list produced by
decoration, and then remove all windows that are not decorations,
which means I remove the unfocused windows.

But leaving the possibility of the other approach too.

Obviously, over the windowRemover every modifier may be thinking that
the layout was produced by Full, but it will receive the decorations
too, but can just skip them when processing the list (what I say decoration
awareness of a modifier)


More information about the xmonad mailing list