January 2008 - xmonad

darcs patch: add --help option
by Lukas Mai 25 Mar '08

25 Mar '08

Wed Jan 30 00:52:58 CET 2008 Lukas Mai <l.mai(a)web.de> * add --help option

2 1

Remote Controlling XMonad: Cases and Materials
by Andrea Rossato 24 Feb '08

24 Feb '08

Hi, this is a follow up of the thread started by Zed Lopez[1] on controlling XMonad remotely. Stefan O'Rear proposed a solution[2] and I implemented it[3]. We briefly discussed this solution on the #xmonad channel[4] and I thought some more documentation was needed on the methodology to use to achieve the goal. allbery_b reported that such an approach has been used by Mozilla, so I wanted to find more examples to study. Zed said that it was missing this feature from Ratpoison.[5] BTW, the successor of Ratpoison, Stumpwm is developed in Common Lisp...;-) So I went to have a look at how ratpoison deals with the subject and this is what I discovered[7,8]. This is what happens in Ratpoison: a. the Client (that sends the command): 1. creates w simple window 1 pixel width 2. sets an atom (RP_COMMAND) with a command to that window 3. sets an atom (RP_COMMAND_REQUEST) in the root window with XChangeProperty: this atom carries the first window id 4. waits for a propertyNotify to be sent to this window b. Ratpoison: 1. gets the property of the root window (which will return the id of the window containing the command string) 2. searches the window with the command string and executes the command 3. writes an atom (RP_COMMAND_RESULT) to the window with the command result. This will send the propertyNotify the will unblock the client. A similar approach is also used by Enlightment (see src/comms.c) and its remote shell Eesh (see Eesh.xs). WMII, instead, uses libipx and a Plan9 approach (I must confess I don't know much about P9), while DWM has no remote control capability. Now, attached you'll find two archives. The first one is a simple way of running commands from an external program, without a two way communication. It is basically a refactoring of the patch I've already sent[3]. It is simple and effective. I had no problem running it here. The second archive (xrcRatpoisonWay.tar.gz) instead is the ratpoison implementation: I literally copied the algorithm. And there's is a problem. This code produces an X server crash every now and then. I cannot reproduce it and, no matter how many times I read it, I cannot find a bug in my code. I believe there's something wrong with Xlib.Extras.rawGetWindowProperty (a null pointer?). Indeed if you change in ServerMode.hs: let c' = Just [118,105,101,119,49] --c' <- io $ getWindowProperty8 dpy c win no more crashes. You may also see that the command execution sometimes fails. Is that something that used to happen in Ratpoison too? Anyway it is something I think it is worth to investigate a bit more. And I think I will. BTW, these patches require a vary small modification to XMonad itself. XMonad has just to wait for a propertyNotify event sent to the root window. If that happens a hook is called (I named that hook serverHook). I do not want you to equivocate: I'm not pushing for this patch to be included, but I thought to report here some of the information I was able to gather on the subject. Moreover, as far as I can understand, there's is not so much interest in this feature. But here this stuff proved to be quite addictive...;-) Thanks for your kind attention. Andrea [1] see http://www.haskell.org/pipermail/xmonad/2007-July/001502.html [2] see http://www.haskell.org/pipermail/xmonad/2007-July/001509.html [3] see http://www.haskell.org/pipermail/xmonad/2007-July/001533.html [4] see http://www.cse.unsw.edu.au/~dons/irc/xmonad/2007-07-26.txt [5] http://www.nongnu.org/ratpoison/ [6] http://www.nongnu.org/stumpwm/ [7] see also http://cvs.savannah.nongnu.org/viewvc/ratpoison/src/communications.c?root=r… [8] see also receive_command() and execute_remote_command() and related comments here: http://cvs.savannah.nongnu.org/viewvc/ratpoison/src/events.c?root=ratpoison… [9] http://search.cpan.org/~rbs/Eesh-0.3/

7 11

XMonad 0.5, combo layouts, swapDown and swapUp
by Dave Harrison 07 Feb '08

07 Feb '08

Hey all, First up, love the new configuration method, my xmonad.hs file is now nice and tiny :-) Quick "maybe glitch" though, I'm using ComboLayout with Tabbed, and I find that when I first add lots of windows to the layout the alt-tab order is correct (also when adding windows into the middle of the stack it's correct). When I swapDown or swapUp _in_ the stack, the order is correct. But if I swapDown or swapUp at either end of the stack the ordering goes rather pearshaped (the ordering is no longer correct "visually" if you see what I mean). Is this a known thing ? My xmonad.hs is below. Cheers, Dave ---- import XMonad hiding (Tall(..)) import qualified XMonad.StackSet as W import XMonad.Layout.Tabbed import XMonad.Layout.Combo import XMonad.Layout.TwoPane import XMonad.Layout.NoBorders import XMonad.Layout.HintedTile import XMonad.Config (defaultConfig) import XMonad.Hooks.DynamicLog import XMonad.Util.Dmenu import qualified Data.Map as M import System.IO (hPutStrLn) daveConfig = defaultConfig { defaultGaps = [(0,15,0,0)] , logHook = dynamicLog , terminal = "xterm -fa Mono -fs 12" , layoutHook = smartBorders ( combineTwo (TwoPane 0.03 0.5) (tabbed shrinkText defaultTConf) (tabbed shrinkText defaultTConf) ||| mytab ||| tiled Tall ||| tiled Wide ||| Full ) , keys = \c -> mykeys c `M.union` keys defaultConfig c } where -- layouts tiled = HintedTile 1 0.03 0.5 mytab = tabbed shrinkText defaultTConf -- key mapping overrides mykeys (XConfig {modMask = modm, workspaces = ws}) = M.fromList $ [((modm, xK_Left ), sendMessage Shrink) -- %! Shrink the master area ,((modm, xK_Right ), sendMessage Expand) -- %! Expand the master area ,((modm, xK_p ), spawn "exe=`cat /home/dave/.dmenulist | dmenu -b -p \"$\"` && eval \"exec $exe\"") -- @@ Launch dmenu ] main = xmonad $ daveConfig

5 9

Trying to code jump-or-execute
by Joseph Garvin 05 Feb '08

05 Feb '08

I'm a former sawfish user, and I used to have this really awesome keyboard shortcut called "jump-or-exec". I would press for example Super+F, and if Firefox was not running, it would be executed, and if it was already running, then it would be given focus. I had similar shortcuts for emacs, terminals, etc. I'm a bit of a haskell newb -- I can tell that I can simply use 'spawn' to launch a process, and if I had a list of current windows I would know how to iterate through them and find out whether one currently exists, but I don't know how to get such a list. Ideally I'd like to be able to match against window title or class. Is there a way to do this with xmonad?

8 8

The future of PerWorkspace
by Brent Yorgey 02 Feb '08

02 Feb '08

Hi all! This may end up being a long e-mail. Executive summary: 1. PerWorkspace is an inelegant hack with several icky problems: - 'description' is not in the X monad so can't figure out the current workspace - the currently focused workspace might not even be the correct one anyway, in the case of xinerama or message handling. 2. Andrea's LayoutCombinator class and core patch to move the result of the description function into the X monad will help with some but not all of the problems. In particular it still won't work with xinerama. 3. It would be nice to have the PerWorkspace functionality supported in the core, and I have a nice, elegant way to do it. This would fix all the problems. ...The only catch is that it would also require going back to requiring existential Layout wrappers everywhere. =( 4. Well, crap. I had recently been thinking about PerWorkspace and ways to improve it, but hadn't yet gotten around to really doing anything about it. Andrea's new emptyLayout function, and then in particular his reimplementation of PerWorkspace using the new LayoutCombinator framework obviously motivated me to get around to it! So I'd like to explain some of the problems with PerWorkspace and possible future directions. First, the basics: although the xmonad core tracks layouts separately for each workspace, it is not possible to *specify* a different starting layout on a per-workspace basis. Only a single layout may be specified in the XConfig record, and this layout is duplicated across all workspaces on xmonad startup. PerWorkspace attempts to get around this limitation by providing a layout which dynamically decides on which of two sub-layouts to use, based on the current workspace tag. All workspaces still have the same layout, but that one layout acts differently depending on the current workspace. You can see from the beginning that this is something of a hack. This approach has two major limitations, each of which leads to one or more problems. * To find out the current workspace obviously requires access to the X monad. For doLayout and handleMessage this is obviously not a problem. The description method, however, is a pure function. I solved this in a very hackish way before by having a call to doLayout return a modified PerWorkspace layout structure with a cached value remembering which of the two layouts should be used. description could then use this cached value to decide on the description to return. Andrea's current reimplementation of PerWorkspace does not do this caching, which is why the description method is currently broken. I can reimplement this, and the new emptyLayout method will help, but it still feels very inelegant. * A more insidious problem is that it is not possible, in general, for doLayout or doMessage to figure out which workspace they belong to, and hence which layout to use. PerWorkspace currently works by retrieving the tag of the currently focused workspace from the xmonad state, but there are several situations in which doLayout or handleMessage are called on a workspace which is not the currently focused workspace: - If xinerama is in use, doLayout will be called for all the visible workspaces as well as the focused workspace. - Messages can be broadcast to all workspaces, in which case handleMessage will be called for all workspaces, including non-focused or even hidden workspaces. In either of these situations, PerWorkspace may choose the wrong layout. The message problem can be solved by simply passing along any messages to all layouts, without trying to decide on the correct one: it cannot hurt to pass messages to unintended recipients, especially if the unintended recipient layouts will never be used anyway! The xinerama problem seems insoluble, however. PerWorkspace simply cannot work on xinerama because it cannot get the information it needs to decide which layout to use. So, what is the way forward? It looks like I can get PerWorkspace back to its original level of workingness --- thanks to the LayoutCombinator class it will be a lot shorter, but it still won't work with xinerama, and it will still be an ugly, fragile hack. I had been intending to suggest adding support for per-workspace layouts to the xmonad core. After all, xmonad does track and save/restore layouts on a per-workspace basis, so why shouldn't it allow configuring them on a per-workspace basis too? I intended to keep the current layoutHook (specifying the default layout to be used on all workspaces not otherwise specified) as well as adding a new field to the config which would store a list of (workspace tag, layout) pairs. The core modifications necessary to support this are not too hard and end up being fairly elegant -- in fact, I have made these modifications in a local branch. The catch? Having a bunch of layouts in a list like this requires going back to wrapping everything with Layout existentials in user configs! =( This doesn't sound like much fun either. So, I am at something of a loss. Any thoughts or suggestions for moving forward are appreciated! -Brent

6 22

some cleanup
by Andrea Rossato 02 Feb '08

02 Feb '08

Hi, I'm now trying to clean up a bit after this long and stressful class ride (I even started dreaming about type classes, such is the addictive power of this stuff). Now I'm going to take a break and enter in a maintainer mode: just debugging and docs. Spencer: I'm still waiting your decisions about tabbed. Should it return all windows and thus use the decoration framework, of should it be e separated layout (the previous one) returning just the focused window? Please, take a decision, because at the present time tabbed is plainly broken (my fault since I gave you wrong information... but I was a bit confused when you asked). Anyway you can just: 1. push a simple patch to make it use Simplest, or 2. get a version of the old tabbed and copy it over the new one: it should be working out of the box (maybe users will have to import it qualified). The reason why it should not return all windows is still a bit mysterious to me... what you said, I don't remember exactly, seemed to me more a bug in the X server then a feature. But I came to be a bit confused on the distinction between the two, lately...;) Bugs may come to me! Andrea

5 10

darcs patch: Always float ediff windows
by Alec Berryman 02 Feb '08

02 Feb '08

ediff is a popular and widely-used interactive diff/merge mode included with emacs. It works by opening up a small window that the user keeps in focus while using ediff commands like next patch; if the main emacs window is in focus, none of the ediff key commands are available. The small window generally obscures what the user is interested in and is kept as small and out of the way as possible; by default, it opens up very tiny in the top right of the screen. The window is already in way just by existing, but having xmonad try to manage it really screws things up. It's in the same class as MPlayer and GIMP; there's no use case for managing it, so do the right thing by default and always float it. I used title instead of className because the className is emacs, and floating all emacs buffers is definitely not the right thing to do. Wed Jan 30 18:38:20 EST 2008 Alec Berryman <alec(a)thened.net> * Always float ediff windows

5 5

ClientMessage events in 0.7?
by Joachim Breitner 01 Feb '08

01 Feb '08

Hi, now that 0.6 is out I’d like to get some attention on a feature needed for more complete EWMH support: The module needs to handle XEvents (ClientMessage events in particular) on a global, not per-layout, scale. I’m not following xmonad development close enough to judge what the best way of doing that would be, but I hope that you’ll find a way... Greetings, Joachim PS: Has anyone tested the Debian packages for 0.6 already? -- Joachim "nomeata" Breitner mail: mail(a)joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata(a)joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata(a)debian.org

4 9

Issue 129 in xmonad: ClassLayout.description type signature is wrong
by codesite-noreply＠google.com 01 Feb '08

01 Feb '08

Issue 129: ClassLayout.description type signature is wrong http://code.google.com/p/xmonad/issues/detail?id=129 Comment #2 by andrea.rossato: > Please demonstrate some layouts that truly need description :: X String. actually here you'll find a layout, CombinedLayout, which takes a layout combinator and two layouts to be combined: http://www.haskell.org/pipermail/xmonad/2008-January/004422.html I think that if you cannot implement description, and you cannot implement description over the layout class, I proved my statement. And I think that if you can you proved I'm wrong. -- 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 128 in xmonad: Mirror mus implement emptyLayout
by codesite-noreply＠google.com 01 Feb '08

01 Feb '08

Issue 128: Mirror mus implement emptyLayout http://code.google.com/p/xmonad/issues/detail?id=128 Comment #3 by SpencerJanssen: Forgot to close. Issue attribute updates: Status: Fixed -- 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

2 1