- xmonad - Haskell.org

RotView readability patch
by Eric Mertens 11 Oct '07

11 Oct '07

Hello, I started using RotView recently, but I felt like the code was rather difficult to understand at a glance. I wanted to share the changes I made in case anyone else felt the same way. Other than some minor code changes and library function usage issues, I did want to say that RotView does exactly what I wanted. (This patch should introduce no new behavior.) -- Eric Mertens Phone: 503.626.6616, x155 Galois Fax: 503.214.8120 12725 SW Millikan Way Ste 290 http://www.galois.com Beaverton, OR 97005-1691 emertens(a)galois.com

3 2

Wmii like actions for xmonad
by Juraj Hercek 11 Oct '07

11 Oct '07

Hello, attached patch implements the wmii like actions (wmii.suckless.org) It basically scans the directory for executables and passes it to dmenu so user can choose one, which is executed afterwards. Regards, Juraj

2 1

darcs patch: one more comment.
by David Roundy 11 Oct '07

11 Oct '07

Thu Oct 11 11:44:23 EDT 2007 David Roundy <droundy(a)darcs.net> * one more comment.

2 1

darcs patch: add comments in XMonad.
by David Roundy 11 Oct '07

11 Oct '07

Thu Oct 11 11:29:42 EDT 2007 David Roundy <droundy(a)darcs.net> * add comments in XMonad. This change also removes readLayout as a top level function, since it's only used once.

2 1

darcs patch: NoBorders bugfix (I hope)
by l.mai＠web.de 11 Oct '07

11 Oct '07

Thu Oct 11 04:17:56 CEST 2007 l.mai(a)web.de * NoBorders bugfix (I hope) David Roundy should probably have a look at this, but this change makes sense to me. Plus it makes NoBorders work in combination with SwitchTrans. :-)

4 3

Issue 58 in xmonad: XMonadContrib docs are broken
by codesite-noreply＠google.com 11 Oct '07

11 Oct '07

Issue 58: XMonadContrib docs are broken http://code.google.com/p/xmonad/issues/detail?id=58 Comment #1 by andrea.rossato: The online documentation relates to the latest release, as every user would probably (and reasonably) expect. If you are using the darcs version you should refer to the modules' source comments. Some of their documentation may be outdated (or not yet updated) and any help to update the documentation is highly appreciated, since, as you said, docs are indeed essential. You said that this applies to xmonad-0.3 too, which, in fact, I cannot reproduce, as I should say. Can you please provide a specific example - or, even better, the complete list of modules whose documentation is wrong? Thank you. Andrea -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

Issue 58 in xmonad: XMonadContrib docs are broken
by codesite-noreply＠google.com 11 Oct '07

11 Oct '07

Issue 58: XMonadContrib docs are broken http://code.google.com/p/xmonad/issues/detail?id=58 New issue report by nomorecolors: What steps will reproduce the problem? Trying to configure most, if not all, of the contribs according to the online docs results in errors, which are hard to grasp and fix for newbies. What is the expected output? What do you see instead? Docs are essential :P What version of the product are you using? On what operating system? darcs version, but it's the same with 0.3 Issue attributes: Status: New Owner: ---- Labels: Type-Defect Priority-Medium -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

darcs patch: add/reformat (commented out) tracing code to SwitchTrans
by l.mai＠web.de 11 Oct '07

11 Oct '07

Thu Oct 11 04:21:39 CEST 2007 l.mai(a)web.de * add/reformat (commented out) tracing code to SwitchTrans

1 0

possible bug in tabbed window extension
by Michael Vanier 11 Oct '07

11 Oct '07

I've just upgraded to the latest xmonad in darcs, and it's great! However, one thing that used to work doesn't work anymore. I bind mod-button3 to the kill command, and when I put the cursor on a tab and hit mod-button3 the entire X server crashes! When I do it outside of a tab it works fine. FWIW the relevant part of my Config.hs is: -- | -- default actions bound to mouse events -- mouseBindings :: M.Map (KeyMask, Button) (Window -> X ()) mouseBindings = M.fromList $ -- mod-button1 %! Set the window to floating mode and move by dragging [ ((modMask, button1), (\w -> focus w >> mouseMoveWindow w)) -- mod-button2 %! Set the window to floating mode and resize by dragging , ((modMask, button2), (\w -> focus w >> mouseResizeWindow w)) -- mod-button3 %! Kill a window , ((modMask, button3), (\_ -> kill)) -- Extension-provided mouse bindings ] Anybody have any idea what's going wrong? TIA, Mike

7 10

More user-friendly hook system
by Joachim Breitner 10 Oct '07

10 Oct '07

Hi, I’ve been given some thought on the way we make the user install the hooks from extensions. Currently, we have two hooks (manageHook and logHook), with a different logic for combining hooks: For manageHook, we pass the window some hopefully useful data as paramenters (name, class) and exepect to get a X (WindowSet -> WindowSet) back. The user can use guards to select which hook to run. Advantage: - relatively easy for the user to add simple custom hooks Disadvantage: - hard to add hooks that need to do X stuff to find out if they have to run (e.g. by getting other Properties of the window). - hard to install hooks so that more than one can run for a window. For loogHook, we just require the user to return an X () action. Advantage: - flexible Disadvantage: - different method than manageHook - user needs to know Monad syntax Additionally, it is hard to add more hook (init hook, hooks on ClientMessage events that would be needed for EWMH interaction), and the user is confused by different hook mechanism. I propose therefore this system: User interface ============== For the user, it should be very simple to add extensions that need hooks. Therefore, there should just be a simple XMonadHook type (where the implementation should not matter to the user), and a single function in the config: > hooks :: [XMonadHook] > hooks = [ewmhHook > , loatGimpHook > , someHookWithAString "text" > , someHookWithConfig someConfig > ] > > someConfig = -- more complicated per-hook information Functionality such as matching a window name on manage (as provided by the current system) should be make possible through an extension on it’s own: See the PropManage extension, which already works like this. Possible implementation ======================= Note that given this user interface, there might other ways to implement this. This is just my idea. Assume we want to support four hooks: initHook, manageHook, clientMessageHook and logHook. We also don’t want to change code in Extensions when new hooks are added. I’d give types to the single hooks: > type InitHook :: X () > type MangageHook :: Window -> X (WindowSet -> WindowSet) > type ClientMessageHook :: ClientMessage -> X () > type logHook :: X() for every hook, we have a “no nothing” default hook: > defaultInitHook :: InitHook > defaultInitHook = return () > defaultManageHook :: ManageHook > defaultManageHook _ = return (id) > defaultClientMessageHook :: ClientMessageHook > defaultClientMessageHook _ = return () > defaultLogHook :: LogHook > defaultLogHook = return () The XMonadHook is then a record of possible hooks, and we bunde the default hooks: > type XMonadHook = XMonadHook { > initHook :: InitHook > ,manageHook :: MangeHook > ,clientMessageHock :: ClientMessageHook > ,logHook :: LogHook > } > defaultXMonadHook :: XMonadHook > defaultXMonadHook = XMonadHook defaultInitHook defaultManageHook defaultClientMessageHook defaultLogHook To run the hooks given by the user, we map the appropriate accessor over config list and fold the types together, depending on the type > runInitHooks :: [XMonadHook] -> X () > runInitHooks = foldl (>>) (return ()) . map initHook > runManageHooks :: [XMonadHook] -> Window -> X (WindowSet -> WindowSet) > runManageHooks hooks window = foldl (.) (id) `fmap` mapM (($window) . manageHook) hooks > runClientMessageHooks :: [XMonadHook] -> ClientMessage -> X () > runClientMessageHooks hooks cm = foldl (>>) (return ()) . map (($ cm) . initHook) > runLogHooks :: [XMonadHook] -> X () > runLogHooks = foldl (>>) (return ()) . map logHook Extensions then can write their own hook(s) and override the appropriate fields of defaultXMonadHook: > module StupidLogger where > > myLogHook :: LogHook > myLogHook = io $ print "State changed" > > stupidLoggerHook :: XMonadHook > stupidLoggerHook = defaultXMonadHook { logHook = myLogHook } As you can see, adding new hooks would not break this module. Hooks that need some configuration (e.g. PropManage the list things to match), you just require a parameter for your hook > module NameMatcher where > > type NameMatcherConf = [String, X()] > > myManageHook :: NameMatcherConf -> ManageHook > myManageHook = ... > > nameMatcherHook :: NameMatcherConf -> XMonadHook > nameMatcherHook conf = defaultXMonadHook { manageHook = myManageHook conf } That’s it so far. Note that this code is untested. If you think this would be a viable user interface or even a reasonable implementation, I’d be willing to implement that today. Greetings, Joachim -- Joachim Breitner e-Mail: mail(a)joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189

3 8