[xmonad] Property vs Query Bool

Adam Vogt vogt.adam at gmail.com
Mon Mar 30 20:10:05 EDT 2009


* On Monday, March 30 2009, Konstantin Sobolev wrote:

>Hello
>
>I'm trying to implement my own LayoutClass which mixes the ideas of IM
>and CombineTwo. It has to contain some predicate as a part of it's
>state, which will tell where to put new windows.
>As I see IM uses WindowProperties for this purpose, but I wouldn't
>like to use it for 2 reasons:
>1. Property essentially duplicates Query Bool.
>2. Property isn't flexible enough. For instance, I can't match a
>window by title substring, while I can easily do it with Query.
>However, there's one problem (and I guess that's why Property was
>introduced): Query doesn't derive Read and Show, and as far as I
>understand it's not so easy to implement them.
>So what should I use, Query Bool with empty (Read, Show)

Another way to pass a function (that is not changed by running the layout), 
is to use a typeclass:

> class IsAQuery a where
>   query :: a -> Query Bool

> data Dummy = Dummy deriving (Read,Show)

> instance IsAQuery Dummy where
>   query _ = do
>     ..... query stuff

> data QLayout q a = QLayout q deriving (Read,Show)
> instance (Reqd q, Show q, IsAQuery q) => LayoutModifier (QLayout q) a
>        where
>     ....

These ideas were used to extend XMonad.Layout.NoBorders (the patch is 
applied in darcs). For two reasons I don't expect that many functions will 
be passed:
    1) there is probably enough flexibility (a number of predefined styles 
    with ways to combine them), without accepting custom functions, and
    2) adding that code directly to the specific module isn't much more 
    work.

This wouldn't be a bad thing to put in XMonad.Utils for allowing functions 
or other things that do not have Read or Show to be passed as parameters to 
layouts:

> class ShowFunction dummy a where
>     apply :: dummy -> a

So that a user could define ex.

> f x = x + 2

It should be possible for template haskell create the following splice (I 
have not yet succeeded at automating this):

> data F = F
> instance Num a => ShowFunction F (a -> a) where
>     apply = const f

This stuff reminds me of implicit parameters which might be more succinct 
alternative. However those are (somewhat arbitrarily) not allowed in class 
constraints.

--
Adam


More information about the xmonad mailing list