* On Thursday, March 25 2010, wagnerdm@seas.upenn.edu wrote:

Nice work, this looks like something I myself would find quite useful! This seems like the perfect kind of thing for xmonad-extras, a sort of "no-man's land" for extensions that are hard to compile for one reason or another. ~d

Quoting Konstantin Sobolev :

...

Hi all,

...

...

Usage: either drop as XKBLayout.hsc in contrib/XMonad/Layout , add to xmonad-contrib.cabal and rebuild Or put into ~/.xmonad/lib/XMonad/Layout as XKBLayout.hsc and run through hsc2hs Then follow instructions from the header. Basically just import and add to the layout hook.

xxkb can still be used as an indicator

I don't see any problems to include this in contrib: To compile XMonad core you need hsc2hs seeing as there is a file XMonad/Main.hsc. hsc2hs is included with ghc-6.12 and I'm almost certain that it was shipped with earlier versions too. XMonad core uses a hsc file too. Perhaps the XKB binding is somthing that should be part of X11 or a separate package on hackage. -- Adam

Hello, On Sat, Mar 27, 2010 at 2:24 AM, Adam Vogt wrote

I don't see any problems to include this in contrib: To compile XMonad core you need hsc2hs seeing as there is a file  XMonad/Main.hsc.

Many thanks for the feedback. Here's a rewritten eventHook-based version that uses ExtensibleState: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=24464 Compiles cleanly with ghc-6.10, unfortunately I don't have 6.12 to try it there. I wasn't aware of ExtensibleState since I was still on a 0.9.1 codebase.. nice stuff. Docks aren't still recognized, even with getInputFocus from Graphics.X11.Xlib.Misc instead of XMonad's W.focus I'll send a patch to contrib once there're no pending corrections.

* On Saturday, March 27 2010, Konstantin Sobolev wrote:

Update. First version works incorrectly with multiple workspaces due to the fact that XMonad creates separate Layout copy for every workspace, so we get a number of independent LayoutModifer (custom data) instances instead of just one. (By the way, why is it necessary?)

For writing actual layouts, keeping layout state per workspace makes more sense (think about what would happen with dual monitors, different layouts per workspace...). It's much easier to go to global state from workspace-local state than the other way around.

It took me some time to find a workaround; it assumes that different workspaces have different tags. Here it goes, version 2:

This assumption is probably true, but I'm not sure how it would compare to keeping track based on the index in the output of W.workspaces... Perhaps it would be better to implement this as a handleEventHook.

http://hpaste.org/fastcgi/hpaste.fcgi/view?id=24417

Here are some suggestions to shorten the code:

http://hpaste.org/fastcgi/hpaste.fcgi/view?id=24417#a24423

-- Adam