On Fri, Feb 01, 2008 at 12:22:32AM -0600, Spencer Janssen wrote:
As far as I know, there has only been one other proposal that solves the Xinerama issues with PerWorkspace -- adding a WorkspaceId argument to doLayout. I think we've all agreed that isn't so nice. My message proposal is actually very similar -- except that only layouts that care about workspace location need to handle these messages, whereas an extra argument to doLayout must be mentioned in every single layout instance.
Have you proposed another implementation that solves the Xinerama issue, and I missed it?
Yes you did. You actually did miss quite a lot of the stuff I've been sending recently. You are not the only one, though. As I say I did not propose to change doLayout, but just to change, in runLayout, doLayout with a doLayoutInWorkspace which takes the workspace and calls "doLayout (layout w)". The same for (emptyLayoutInWorkspace w = emptyLayout (layout w) and handleMessage. Did you read this message and the attached patch? http://www.haskell.org/pipermail/xmonad/2008-January/004493.html If a layout may be knowing the workspace it is running on, we could implement a general purpose combinator (my LayoutCombinator class and a general purpose CombinedLayout, implemented on top of the layout class. If we get to class level composition - by changing the description type, we can implement ANY combinator within the layout hook. Combinators, in this case, may be receiving messages and run one, layout, run the other, run both and combine their result, or run none, handle the message, and return a new combinator. This solves xinerama and we can eliminate duplicate code in Choose, NewSelect, ToogleWorskpace, PerWorkspace. As I mention here: http://code.google.com/p/xmonad/issues/detail?id=129 (I answered to your challenge, but you did not to mine!), with my proposal, PerWorkspace implementation would be: instance LayoutCombinator PerWorkspace a where chooser (PerWorkspace wsIds) = do t <- getCurrentTag return $ if t `elem` wsIds then DoFirst else DoSecond Obviously here I'm using class level composition. Can you really claim your implementation would be cleaner? Show me the code, please. I showed mine, which is actually working. That implementation IS ACTUALLY working and has been in xmc repository for a couple of days. Than I had to remove it since I asked for core support and I was told I would not get it. So, I removed it. And I asked you to forget all related patches. Cheers, Andrea