* Konstantin Sobolev [2009-03-30 00:54:03-0400]

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.

You are right.

So what should I use, Query Bool with empty (Read, Show) implementations, losing state between restarts; or Property losing flexibility that I'd like to have?

You should use Property. Concerning flexibility, if you can not discriminate windows by exact matches, it's typically a problem with that application and is a reason to submit a bug report. -- Roman I. Cheplyaka (aka Feuerbach @ IRC) http://ro-che.info/docs/xmonad.hs

* 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