On Thu, Jan 31, 2008 at 09:47:15AM +0100, Joachim Breitner wrote:

I already submitted that, but then the event was handled once per layout, which is too often − I need a way to reliably intercept the event exactly once.

I may be wrong, but probably what you need is a layout combinator: you get the message and you return a new combinator that will decide what to do next. with the LayoutCombinator class and the CombinedLayout instance that would be a trivial task. But the sense of beauty you may find here would suggest: data Interceptor l1 l2 a = Intercept Bool DoNex (l1 a) (l2 a) deriving (Read, Show) data DoNext = Wait | GoTakeACoffee | RunAAlyout | OrJustTakeASnap deriving ... then you implement a LayoutClass instance for Interceptor with plenty of unmaintainable boilerplate code: instance (LayoutClass l1 a, LayoutClass l2 a) => LayoutClass (Interceptor l1 l2) a where doLayout emptyLayout to get to: handleMessage (Intercept b d l1 l2) m = if b the do do something with do DoNext return (Just Intercept True GoTakeACoffee l1 l2) but you'll be rewarded with a wonderful pure method for setting the combinator descriptor. This is real easy: description _ = "I'm a pure f***ing string" You may also want to run the message on those layouts too and then return them updated. Be careful, if you do everything by hand you can really mess everything up. moreover, I will not be of any help when the next API change will break all you wonderfully designed stuff. I know, a LayoutCombinator class would make all that quite easy, but can you imagine how ugly would it be having to write: description _ = return "Sorry, Andrea wanted me unpure" ?? ;) cheers, andrea I'm just kidding. :)

On Thu, Jan 31, 2008 at 01:09:49PM -0600, Spencer Janssen wrote:

Think about what will happen when there are multiple visible workspaces -- ie. Xinerama.

actually we were discussing just that a couple of threads above with Brent, and we came up with a couple of class methods that could just solve this problem, by passing to the layout the Workspace it is going to be run on. Brent rejected that, because it would bloat the LayoutClass. And he may have a point, as long as extending a class is bad. as you know I don't get xinerama quite well, but as far as I get it in a xinerama setup a workspace cannot be in two screens at the same time. Am I right? cheers, Andrea

On Fri, Feb 01, 2008 at 12:08:24AM -0600, Spencer Janssen wrote:

The problem is that these EWMH events should be processed by the window manager only once, globally -- so we have a problem if two workspaces with the EWMH layout modifier are visible at the same time (this will always happen if the user defines it as part of their layout hook and there are two or more monitors).

As I said in the previous message, with class level composition I can (I did!) implement an abstract combinator that can just do that: if a give condition is met, the combinator may handle the message even *without* running the layout. I believe that the combinaotr semantics is an unknown object here. I've been investigating it, since I wrote a class to map it. I know how much powerful it can be. But if I'm wrong I'd like you to show me where I get it wrong. Cheers Andrea