January 2012 - xmonad

Going Gnomeless (and Unityless on Oneiric)
by Jacek Generowicz 19 Jan '12

19 Jan '12

Greetings, I'm returning to Linux after almost a decade away, and finally being able to fully XMonadise my environment is a great (though time-consuming) joy: The efficency of a finely tuned and customized, all-encompassing XMonad setup is quite awesome. I apologize if I get some of the current Linux terms long, in what follows. I'm on Ubuntu Oneiric and have been running XMonad under Unity (which seems to be partially built on Gnome?) I see a way forward for getting rid of all Gnome or Unity features and replacing them with some combination of XMonad, xmobar, dzen, conky etc., except for two: - Gnome seems to do a fairly decent job of automatically detecting and managing wireless networks. How would I go about this without Gnome's assistance? Is there something that can be plugged into XMonad which will show me available networks, and allow me to choose, connect and disconnect (preferably without having to touch the mouse, but also without having to type magic incantations involving wpa_supplicant, iwconfig etc.) ? - What's the quickest way of accessing system settings. I've been trying to run without the unity panel and launcher, but I've had to respawn them just to get access to system setting. Thank you.

8 30

Issue 492 in xmonad: GTK windows do not repaint when switching from an Aqua application to X
by codesite-noreply＠google.com 17 Jan '12

17 Jan '12

Status: New Owner: ---- New issue 492 by cubra...(a)gmail.com: GTK windows do not repaint when switching from an Aqua application to X http://code.google.com/p/xmonad/issues/detail?id=492 What steps will reproduce the problem? 1. press Cmd-Shift-A to get out of X root window and then Alt-Tab to switch to an Aqua application 2. press Alt-Tab to switch back to X 3. gnome-terminal and other GTK applications (installed through MacPorts) do not repaint their windows unless I switch to another workspace and back. Other X apps like xterm repaint fine. What is the expected output? What do you see instead? All running windows should repaint What version of the product are you using? On what operating system? xmonad 0.9.1 on Mac OS X 10.6 (Snow Leopard)

1 1

Re: [xmonad] renameWorkspace and autoComplete
by Jacek Generowicz 17 Jan '12

17 Jan '12

At Tue, 17 Jan 2012 18:19:26 +0100, Matthias Hörmann wrote: > You don't have to use the same XPConfig for all of them. Ahem, yes, that's rather obvious, now that you mention it. Thank you. > You could use one with autocomplete for selecting and one without > for creating new workspaces, couldn't you? Yes, tried it, it works. But it does eat up one extra modifier on my workspace switching key (and I was planning to use it for something else), so I would still be interested in suggestions on how to get the autocomplete delay to allow specifying new names.

1 0

renameWorkspace and autoComplete
by Jacek Generowicz 17 Jan '12

17 Jan '12

Hello, I am using DynamicWorkspaces and have switched on autoComplete. Consequently, when I start working on some new 'thing' I can quickly create a new workspace for it, and switching between arbitrary named workspaces is very quick: Mod-<my-dynamic-workspace-key> <first-letter-of-workspace-name> is all it takes, because autocomplete selects the namespace as soon as only one matching completion remains (and my namespaces have unique initials, to start with). Switching to a namespace which does not exist, creates that namespace. And here is where autocomplete gets in the way: if I want to create a namespace with an initial that already exists, autoComplete will select the existing namespace without giving me the opportunity to give a new name. The autoComplete config member is a Maybe Int: 'Nothing' means do not autocomplete; 'Just us' means wait for 'us' microseconds before autocompleting. I thought that increasing this delay slightly would give me the opportunity to type the name of a new namespace that I want to create. Not so: it just waits, but then picks the originally chosen one anyway. Any hints on how to get autoComplete and selectWorkspace to allow creation of new namespaces with names with initials which are shared by other already-existing namespaces? Thanks.

1 0

One status bar process, visible on N screens
by Jacek Generowicz 17 Jan '12

17 Jan '12

Hello, When running unity-2d-panel, the panel appears once on each screen, even though a single process is running. (There is a glitch where the width of the narrower screen determines the width of the panel, so it doesn't span the whole screen width on the wider screen.) At the moment I am spawning two xmobar or dzen2 processes, one for each screen. This isn't really satisfactory: Requiring multiple processes merely to display exactly the same information, and hard-wiring 2 bars, is rather grating. Have you any suggestions on how to configure XMonad so that a single status bar is visible on every visible screen that happens to be connected at any time? Thank you.

3 6

Issue 491 in xmonad: Incorrect documentation in XMonad.Actions.WindowGo
by codesite-noreply＠google.com 16 Jan '12

16 Jan '12

Status: New Owner: ---- New issue 491 by cub.ua...(a)gmail.com: Incorrect documentation in XMonad.Actions.WindowGo http://code.google.com/p/xmonad/issues/detail?id=491 Documentation for XMonad.Actions.WindowGo (http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Actions-WindowGo.html) have incorrect link. At the end of raiseMaybe description, instead of : ... to run Mutt! Here's an example (borrowing runInTerm from XMonad.Utils.Run): should be: ... to run Mutt! Here's an example (borrowing runInTerm from XMonad.Util.Run): (both visible text and link to XMonad.Util.Run are affected)

1 1

Avoiding multiple status bar processes after XMonad restart
by Jacek Generowicz 15 Jan '12

15 Jan '12

Hello, Would you have any advice on avoiding multiple xmobar or dzen processes running as a consequence of XMonad restarts? Is there really nothing built in to XMonad that deals with this, or have I simply failed to find it? Thanks.

4 13

(no subject)
by Chris Pick 15 Jan '12

15 Jan '12

I've been playing around with XMonad and came across the helpful PhysicalScreens extension. The extension works well, but I had a small hiccup getting started. As a Haskell and XMonad novice, I was pretty much copying/pasting from the example at http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Actions-PhysicalScreens… that's pulled from the source. The import line contains a typo, it says "PhysicalSCreens" instead of "PhysicalScreens". I grabbed what I believe is the latest source with `darcs get http://code.haskell.org/XMonadContrib` and the typo is still there. I mailed Nelson Elhage, who let me know that this list would be the best place to submit a patch. Gratuitously simple patch attached.

2 1

dmenu on currently focused monitor
by Jacek Generowicz 13 Jan '12

13 Jan '12

Hi, At the moment I'm invoking dmenu with spawn "exe=`dmenu_path | dmenu` && eval \"exec $exe\"" Which results in dmenu always appearing on my primary monitor. What should be done in order to make dmenu appear on the focused monitor? I'm guessing that it might require the use of dmenu's -m option, but it's not clear to me how to get XMonad to report the currently focused monitor, or how to (cleanly) incorporate this information into the spawn command. As a secondary issue, when monitor 1 is focused and I launch something with dmenu, dmenu appears on monitor 0; the launched application sometimes appears on monitor 0, sometimes on monitor 1. I haven't managed to spot a pattern in this behaviour yet. Any hints on how to make this behaviour more stable and more sensible? Thanks.

2 2

Re: [xmonad] [process] Fixed asynchronous exception bugs in readProcess and readProcessWithExitCode
by Brandon Allbery 13 Jan '12

13 Jan '12

On Thu, Jan 12, 2012 at 14:35, Bas van Dijk <v.dijk.bas(a)gmail.com> wrote: > 2) If an asynchronous exception was thrown to the > stdout/stderr-read-thread it did not execute the putMVar anymore > resulting in a dead-lock when takeMVar was executed. > Hah. I knew something like this was in there; xmonad is hanging instead of catching an exception or signal when the far end of a pipe (usually xmobar) goes away. -- brandon s allbery allbery.b(a)gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

2 1