June 2009 - xmonad - Haskell.org

darcs patch: Add ifWindow and ifWindows and simplify WindowGo
by Daniel Schoepe 25 Jun '09

25 Jun '09

2 1

xmonad vs. full screen
by Thomas Friedrich 24 Jun '09

24 Jun '09

Hi everyone, In earlier versions of xmonad, when pressing the full screen button while watching a flash-movie, a new window would be opened, integrated in whichever layout one was using at the time, and the video, now running in "full-screen-mode", would take as much screen-real-estate as xmonad was willing to let it have. This behavior has changed with recent versions of xmonad (or at least the version that I am currently running). A new window with the movie is still created, however, the movie now runs with the same resolution as the screen. For example, if you're running the Tiled-layout and start a flash-movie within Firefox, you would see the Firefox-window on the right and the video-window on the left, however, now the movie being cut off in the middle. (I also have the issue that when the video-window is loosing focus, it disappears, e.g. when moving the mouse out of the window, or when changing layouts, or when switching workspaces.) I was always thinking of the old behavior of xmonad as a feature. A program running in "full-screen" would optimize itself according to the real-estate you -- as a user -- are willing to give to it. This had great advantages. You could watch a taped university lecture on youtube in full-screen WHILE looking things up on the web, etc. This is not possible anymore, as each program running in "full-screen-mode" actually thinks that it would have the *full screen* available. So, I have two questions. 1) I compiled xmonad from source. Where in the code would I need to change what to get the old behavior back, handling full-screen movies? I would be really thankful, if someone could point me into the right direction. Where to look, what to change, etc.? Or even better, is it possible to trigger this within ones xmonad.hs? Thanks so much for help. 2) I would propose going back to the old behavior of handling full-screen-programs in xmonad. It really should be the *user* who decides how "full-screen" a full-screen-program shall be. Isn't this also more following the philosophy of xmonad? You as a user decide, what is happening on your screen? It might be not as intuitive, when switching to xmonad and you are used to other WMs, where full-screen means *full screen*. I really miss that functionality, now that its gone. What do you think? Cheers, Thomas

4 5

runOrRaise changes
by Gwern Branwen 24 Jun '09

24 Jun '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I have just pushed the following patches to XMC. One just tidies up the haddocks in WindowGo, and one adds a convenience function to Utils.Run. The third one changes the internals of WindowGo to use safeSpawn instead of spawn/going via /bin/sh. I have made the last change because after looking through the config archive, it seems every use of the runOrRaise functions simply specifies a program name; so spawn is just unnecessary & cluttering up the process tree. As I said, this shouldn't adversely affect anyone who just does stuff like 'runOrRaise "emacs"' or 'runOrRaise "firefox"'; but it's possible that there's someone who is doing shell scripting in the argument and so whose binding would be broken by this. So this is a heads up for them. The 4th and fifth patches are because I discovered that when Emacs is passed "" as an argument, it either bombs out or opens a new file by that name. (I'm not clear how the latter is possible...) The problem is the old version of safeSpawn only took a String, and not a [String]. I could've added a check for "", but it's more principled to express the need directly. This, unfortunately, breaks 2 configs and a number of modules. The fifth patch fixes the modules, but I cannot do anything about Sean or 31d1's configs. (But at least it's easy to update callers.) Mon Jun 22 15:28:31 EDT 2009 gwern0(a)gmail.com * XMonad.Actions.WindowGo: improve haddocks { hunk ./XMonad/Actions/WindowGo.hs 72 - user. Currently, there are three such useful booleans defined in - "XMonad.ManageHook": title, resource, className. Each one tests based pretty + user. Currently, there are 3 such useful booleans defined in + "XMonad.ManageHook": 'title', 'resource', 'className'. Each one tests based pretty hunk ./XMonad/Actions/WindowGo.hs 75 - useful of which is (=?). So a useful test might be finding a Window whose + useful of which is (=?). So a useful test might be finding a @Window@ whose hunk ./XMonad/Actions/WindowGo.hs 138 - if your variables are simple and look like 'firefox' or 'emacs'. -} + if your variables are simple and look like \"firefox\" or \"emacs\". -} hunk ./XMonad/Actions/WindowGo.hs 143 -{- | if the window is found the window is focused and the third argument is called +{- | If the window is found the window is focused and the third argument is called hunk ./XMonad/Actions/WindowGo.hs 145 - See 'raiseMaster' for an example -} + See 'raiseMaster' for an example. -} hunk ./XMonad/Actions/WindowGo.hs 154 -{- | if the window is found the window is focused and the third argument is called - otherwise, raisef is called -} +{- | If a window matching the second arugment is found, the window is focused and the third argument is called; + otherwise, the first argument is called. -} hunk ./XMonad/Actions/WindowGo.hs 160 - otherwise, the first argument is called + otherwise, the first argument is called. hunk ./XMonad/Actions/WindowGo.hs 162 - raiseMaster (runInTerm \"-title ghci\" \"zsh -c \'ghci\'\") (title =? \"ghci\") -} + > raiseMaster (runInTerm \"-title ghci\" \"zsh -c \'ghci\'\") (title =? \"ghci\") -} hunk ./XMonad/Actions/WindowGo.hs 166 -{- | if the window is found the window is focused and set to master - otherwise, action is run +{- | If the window is found the window is focused and set to master + otherwise, action is run. hunk ./XMonad/Actions/WindowGo.hs 169 - runOrRaiseMaster \"firefox\" (className =? \"Firefox\")) $ + > runOrRaiseMaster \"firefox\" (className =? \"Firefox\")) $ } Shall I push this patch? (3/5) [ynWsfvplxdaqjk], or ? for help: y Mon Jun 22 15:30:18 EDT 2009 gwern0(a)gmail.com * XMonad.Util.Run: +convenience function for safeSpawn which drops args to the prog { hunk ./XMonad/Util/Run.hs 24 + safeSpawnProg, hunk ./XMonad/Util/Run.hs 113 +-- | Like 'safeSpawn', but only takes a program (and no arguments for it). eg. +-- +-- > safeSpawnProg "firefox" +safeSpawnProg :: MonadIO m => FilePath -> m () +safeSpawnProg = flip safeSpawn "" + } Shall I push this patch? (4/5) [ynWsfvplxdaqjk], or ? for help: y Mon Jun 22 15:32:55 EDT 2009 gwern0(a)gmail.com * XMonad.Actions.WindowGo: switch to safeSpawn, since everyone just passes a prog name (no shell scripting) { hunk ./XMonad/Actions/WindowGo.hs 37 -import XMonad (Query(), X(), withWindowSet, spawn, runQuery, liftIO) +import XMonad (Query(), X(), withWindowSet, runQuery, liftIO) hunk ./XMonad/Actions/WindowGo.hs 43 +import XMonad.Util.Run (safeSpawnProg) hunk ./XMonad/Actions/WindowGo.hs 63 --- | 'action' is an executable to be run via 'spawn' (of "XMonad.Core") if the Window cannot be found. +-- | 'action' is an executable to be run via 'safeSpawnProg' (of "XMonad.Util.Run") if the Window cannot be found. hunk ./XMonad/Actions/WindowGo.hs 66 -runOrRaise = raiseMaybe . spawn +runOrRaise = raiseMaybe . safeSpawnProg hunk ./XMonad/Actions/WindowGo.hs 107 -runOrRaiseNext = raiseNextMaybe . spawn +runOrRaiseNext = raiseNextMaybe . safeSpawnProg hunk ./XMonad/Actions/WindowGo.hs 158 -runOrRaiseAndDo = raiseAndDo . spawn +runOrRaiseAndDo = raiseAndDo . safeSpawnProg } - -- Mon Jun 22 16:14:01 EDT 2009 gwern0(a)gmail.com * XMonad.Util.Run: improve definition so this can be used with emacs { hunk ./XMonad/Util/Run.hs 110 -safeSpawn :: MonadIO m => FilePath -> String -> m () -safeSpawn prog arg = liftIO (try (forkProcess $ executeFile prog True [arg] Nothing) >> return ()) +safeSpawn :: MonadIO m => FilePath -> [String] -> m () +safeSpawn prog args = liftIO (try (forkProcess $ executeFile prog True args Nothing) >> return ()) hunk ./XMonad/Util/Run.hs 117 -safeSpawnProg = flip safeSpawn "" +safeSpawnProg = flip safeSpawn [] hunk ./XMonad/Util/Run.hs 130 -safeRunInTerm options command = asks (terminal . config) >>= \t - -> safeSpawn t (options ++ " -e " ++ command) +safeRunInTerm options command = asks (terminal . config) >>= \t - -> safeSpawn t [options, " -e " ++ command] } Shall I push this patch? (3/4) [ynWsfvplxdaqjk], or ? for help: y Mon Jun 22 16:14:23 EDT 2009 gwern0(a)gmail.com * update callers of safeSpawn { hunk ./XMonad/Actions/Search.hs 234 -search browser site query = safeSpawn browser $ site query +search browser site query = safeSpawn browser [site query] hunk ./XMonad/Prompt/Shell.hs 80 - where run = safeSpawn c . encodeOutput + where run = safeSpawn c . return . encodeOutput hunk ./XMonad/Util/XSelection.hs 132 -safePromptSelection app = join $ io $ liftM (safeSpawn app) getSelection +safePromptSelection app = join $ io $ liftM (safeSpawn app . return) getSelection hunk ./XMonad/Util/XSelection.hs 139 -transformPromptSelection f app = join $ io $ liftM (safeSpawn app) (fmap f getSelection) +transformPromptSelection f app = join $ io $ liftM (safeSpawn app . return) (fmap f getSelection) } - -- gwern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREKAAYFAko/5xQACgkQvpDo5Pfl1oIpcgCfV41W93RDc/aOS7VjE2ZmFZ5y wfoAn0H5YlagUmFwNbnSGjyuYzRq4wXA =zeQZ -----END PGP SIGNATURE-----

3 2

darcs patch: Generalize Actions.SpawnOn
by Daniel Schoepe 22 Jun '09

22 Jun '09

2 1

Issue 177 in xmonad: xmonad does not follow ICCCM and ignores WM_TAKE_FOCUS protocol
by codesite-noreply＠google.com 22 Jun '09

22 Jun '09

Comment #11 on issue 177 by gereedy: xmonad does not follow ICCCM and ignores WM_TAKE_FOCUS protocol http://code.google.com/p/xmonad/issues/detail?id=177 Here's my take at a better patch that I believe correctly implements each of the focus models specified by ICCCM. The main difference to the previous patch posted here is that setInputFocus is not called when the input hint is not set. I get better results on netbeans that I did with the previous patch. Attachments: takefocus.darcs-patch 9.9 KB -- 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: Expand Tabbed documentation to describe mouse clicks p...
by Dmitry Astapov 21 Jun '09

21 Jun '09

Mon Jun 22 00:19:47 EEST 2009 Dmitry Astapov <dastapov(a)gmail.com> * Expand Tabbed documentation to describe mouse clicks processing

2 1

darcs patch: Provide means to find original window by... (and 1 more)
by Dmitry Astapov 21 Jun '09

21 Jun '09

Sun Jun 21 22:46:52 EEST 2009 Dmitry Astapov <dastapov(a)gmail.com> * Provide means to find original window by its decoration. In order to enable user to write custom `decorationMouseFocusHook' and `decorationMouseDragHook' hooks we need to provide him with means to lookup original window by its decoration. Module Decoration has internal function `lookFor' for exactly the same purpose. I exported it under a slightly different name and without exposing internals of DecorationState. Sun Jun 21 22:52:25 EEST 2009 Dmitry Astapov <dastapov(a)gmail.com> * Close tabs by middle click on tab decoration I'd better do it in xmonad.hs, but I can't decide what to expose from Tabbed.hs to make it happed. Suggestions on how to make mouse click handling hook a part of the Tabbed creation interface are very welcome - my attempts turned out to be ugly in extreme.

2 1

Fwd: Issue 276 in yi-editor: HConf should be a standalone package
by Gwern Branwen 21 Jun '09

21 Jun '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I support this bug, and so there's probably going to be an HConf upload to Hackage soon. It seems to me that XMonad could probably drop the custom loading code in favor of this library. - ---------- Forwarded message ---------- From: Date: Sun, Jun 21, 2009 at 1:46 AM Subject: Issue 276 in yi-editor: HConf should be a standalone package To: yi-devel(a)googlegroups.com Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 276 by Will.Donnelly: HConf should be a standalone package http://code.google.com/p/yi-editor/issues/detail?id=276 This should be a fairly self-explanatory suggestion. With the fixes detailed in issues #274* and #275**, the HConf code is fully capable of being used as a standalone component in any project. All that remains is the process of setting it up for Cabal, and uploading it to Hackage. Benefits to the Yi project would include decreasing the quantity of non-editor code in the main distribution, as well as making it easier for others to use HConf, which in turn leads to a higher-quality library. A tarball of a basic Cabal setup for HConf is included. Many of the usual fields are left blank due to my not knowing the correct answers, but the package is complete and capable of being built and installed. (And used by other projects, naturally) * http://code.google.com/p/yi-editor/issues/detail?id=274 ** http://code.google.com/p/yi-editor/issues/detail?id=275 Attachments: hconf.tar 50.0 KB - -- gwern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREKAAYFAko+QJQACgkQvpDo5Pfl1oIJ0gCfRSAyA1fWGJx3WeDPtC8vBBGC zDAAoJwV7IWBtddAT7C+xebnuD7xyzpS =LgVJ -----END PGP SIGNATURE-----

3 2

XMonad.Actions.Volume
by wagnerdm＠seas.upenn.edu 20 Jun '09

20 Jun '09

I've written a module to interface with the command-line utility "amixer". It tries to be relatively smart about dealing with devices with lots of different controls, and has a fallback interface for when smart is wrong. It includes a full parser for amixer's output, as well, though currently it only reports two aggregate statistics: total volume among all channels and mute-ness. This is probably something of a controversial patch: it adds two dependencies. I don't think the "parsec" dependency is a big deal, since that comes with GHC, and we can therefore expect most users to have it already. The other dependency is the "split" package. Let me know if you want me to just pull in the definition of the particular splitting function I'm using. Cheers! ~d

4 5

XMonad.Layout.WindowNavigation: configurableNavigation (navigateColor "#00aa00") $
by David Chanters 19 Jun '09

19 Jun '09

Hi all, I'm using: XMonad.Layout.WindowNavigation ... and have (from somewhere) the following: , layoutHook = configurableNavigation (navigateColor "#00aa00") $ TL.toggleLayouts (noBorders Full) $ mkToggle (REFLECTX ?? EOT) $ mkToggle (REFLECTY ?? EOT) $ (smartBorders (Grid ||| tiled ||| Full)) When I focus different window, the window borders change color, but i don't know *what* the different colors represent. I tried reading: http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Layout-WindowNavigation… but didn't find anything relevant. Can someone else enlighten me? :) David

2 1