February 2011 - xmonad

Segmentation fault in fromMessage
by Nathaniel Filardo 14 Feb '11

14 Feb '11

I'm defining a LayoutModifier which handles a message: > data SLS sl a = SLS !String !(Maybe ScreenId) !sl !Bool > deriving (Show,Read) > data SLSSetScreen = SLSSS (Maybe String) (Maybe ScreenId) > deriving (Show,Read,Typeable) > instance Message SLSSetScreen > instance (Read (sl a), LayoutClass sl a) > => LLM.LayoutModifier (SLS (sl a)) a where > -- ... > handleMess (SLS t _ sl _) m > | Just (SLSSS mt mns) <- fromMessage m = do > io $ putStrLn (show mt) > return Nothing Sending this a message like so triggers a segmentation fault: > broadcastMessage (SLSSS (Just "foo") (Just 0)) The fault occurs within Maybe's show function, according to gdb, but beyond that I'm not sure what to test. At least this trivial round-trip gives the correct results at a GHCI prompt or when compiled: > let x :: Maybe SLSSetScreen = fromMessage $ SomeMessage (SLSSS (Just "") (Just 0)) in show x This is using a stock Debian GHC > The Glorious Glasgow Haskell Compilation System, version 6.12.1 and a few patches to xmonad (notably, to enable the threaded runtime, but I only spawn off threads that manipulate MVars, nothing near X11 nor this particular component; the full set of patches can be seen at https://github.com/nwf/xconfig/blob/0069880d1389b6e94fa2254073a6b8fb80f9b82… and https://github.com/nwf/xconfig/blob/0069880d1389b6e94fa2254073a6b8fb80f9b82… ) Any help would be greatly appreciated. Thanks much. --nwf;

1 1

Not Showing Current Layout in xmobar
by Eyal Erez 13 Feb '11

13 Feb '11

Hi, I'm using xmobar with John Goerzen's configuration: , logHook = dynamicLogWithPP $ xmobarPP { ppOutput = hPutStrLn xmproc , ppTitle = xmobarColor "green" "" . shorten 50 } However, I'd like to exclude the name of the current layout from display, but keep everything else as is. How can I do that? Thank you

2 1

xmobar troubles
by Tony Morris 13 Feb '11

13 Feb '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I am trying to run a script to check gmail as described here (with some errors) https://wiki.archlinux.org/index.php/Xmobar#Gmail_integration When I set the template to %mail% and restart xmobar, the bar refuses to display. If I set the script to a non-existent file, I see xmobar with a message "Could not execute command", so I know it's all configured fine, but for the script that checks gmail. If I run that script manually, I see a single integer value on standard output. I can't seem to find any place that xmobar is logging to help identify what is causing the error (xmobar refusing to display when asked to Run Com my script. Thanks for any pointers. - -- Tony Morris http://tmorris.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1VLWkACgkQmnpgrYe6r60iTQCgmf3LImIGVUUPFwhyDqYZX15M LeUAoIKI+YD7Wf24++EehLBZ0BhoB+nN =41a2 -----END PGP SIGNATURE-----

3 5

xmonad on Ubuntu 10.04 PPC on PowerBook G4
by Jacob Beard 12 Feb '11

12 Feb '11

Hi, I'm trying to get xmonad to work on my PowerBook G4 running Ubuntu 10.04 PPC. I'm running into a problem where xmonad doesn't seem to be reacting to any commands I send it. For example, if I try to switch workspaces using "mod 2", nothing will happen. If I have a terminal window open when I attempt this, the cursor will blink, but nothing else will happen. I'm running xmonad under Gnome with the Gnome integration hooks, and this works fine on my PC hardware. I have tried the following steps to troubleshoot: * Changing the modifier from the default (Alt), to Super (Apple command key). The same behavior occurs. * Launching xmonad standalone, without Gnome My xmonad configuration is the following: http://pastebin.com/H0M9Rw4J I've also captured the output of xev with input "alt space" under xmonad: http://pastebin.com/spYtG0B6 If anyone has any insight into how I could fix or further diagnose this, I'd appreciate it if you could let me know. Thanks, Jake

1 0

Ditching Gnome
by Eyal Erez 12 Feb '11

12 Feb '11

Hi, I've been using xmonad on top of gnome for some time now. I would really like to drop gnome, and use xmonad straight up. However, gnome has a number of small but significant features that I need to find replacements for: Must Have: 1. System tray: This is where many apps I use (e.g. Pidgin, Skype, Aqualung, Dropbox, etc.) place icons so I can see some status about them, and sometimes interact with them (though mostly just status). 2. Network: This also exists in the system tray but I separated it out because it's really important. This is the ability to see if I am connected or not, and to be able to choose wifi networks to connect to. 3. gnome-do: I use this as an easy way to launch applications. I don't use most of the more complicated features like combining objects and verbs. Nice to Have: 4. High-level view of all desktops and which apps are running on each. 5. Date, time, and whether. 6. System statistics. I have tried both xmonbar and dzen2, but had a hard time getting all the features I needed to work. I was hoping someone can point out what I can use to replace each of these, and throw in some good documentation to boot. I would love to ditch Gnome. Thanks for your help.

6 5

Issue 434 in xmonad: Added a sticky list to rename and a callback if a workspace was removed
by codesite-noreply＠google.com 11 Feb '11

11 Feb '11

Status: New Owner: ---- New issue 434 by que...(a)gmail.com: Added a sticky list to rename and a callback if a workspace was removed http://code.google.com/p/xmonad/issues/detail?id=434 Hi, As I want to preserve a list of sticky workspaces (for use with topicspaces) I dont want them to be removed by renaming. Therefore I added a method that can be used to recreated missing workspaces if they are in a list of sticky ones. Additionally a method the removeEmptyWorkspaceAfterExcept has been extended by removeEmptyWorkspaceAfterExceptExecuteAfterChange such that a given function is called if a workspace was removed. This is useful if there is some information attached to the WorkspaceId that should be removed together with the workspace. Best regards, Jan Attachments: DynamicWorkspaces.hs 9.1 KB

1 0

Compilation error in darcs xmonad-contrib
by Toby Cubitt 08 Feb '11

08 Feb '11

For a little while now, I've been unable to compile xmonad-contrib from darcs. Now that the repo is back up, I tried again, but am still getting the same error as before: [ 34 of 212] Compiling XMonad.Hooks.ICCCMFocus ( XMonad/Hooks/ICCCMFocus.hs, dist/build/XMonad/Hooks/ICCCMFocus.o ) XMonad/Hooks/ICCCMFocus.hs:43:17: Ambiguous occurrence `atom_WM_TAKE_FOCUS' It could refer to either `XMonad.Hooks.ICCCMFocus.atom_WM_TAKE_FOCUS', defined at XMonad/Hooks/ICCCMFocus.hs:34:0 or `XMonad.atom_WM_TAKE_FOCUS', imported from XMonad at XMonad/Hooks/ICCCMFocus.hs:27:0-12 This is with ghc 6.12.3, and version 1.5.0.0 of the haskell X11 libraries. Is there something amiss with my xmonad/haskell setup, or is there an error in the current darcs xmonad-contrib? Thanks for any help, Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: tsc25(a)cantab.net web: www.dr-qubit.org

3 5

GridSelect and the enter key
by Tony Morris 08 Feb '11

08 Feb '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have set up a first-time user with xmonad remotely. He is reporting that everything works perfectly except for GridSelect* where he is able to navigate around the grids with the arrow keys but the enter key does nothing. I would like to provide you with a short xmonad.hs file but unfortunately, he knows nothing about haskell and he is on the other side of the world from me. However, I have mapped GridSelect for him as follows: (mod4Mask, xK_g) -> goToSelected gsConfig (mod4Mask, xK_e) -> spawnSelected gsConfig ["firefox", "idea", "gedit", "ktorrent"] He is running with a GNOME configuration (gnomeConfig). He reports that the enter key fails to work for both mod-e and mod-g. If anyone can provide me with hints to solving this for him, I'd most appreciate it. Thanks. * http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Actions-GridSelect.html - -- Tony Morris http://tmorris.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1RLLQACgkQmnpgrYe6r61NIQCgm25XUEd1slvr2EJr4785qZo2 CfoAoJeqCGlBJOUciRedkQwUELL1aFyU =h5CL -----END PGP SIGNATURE-----

1 0

Xine woes
by Norbert Zeh 08 Feb '11

08 Feb '11

Hi folks, I've seen the following odd behaviour with xine on my dual-screen setup. I open xine on the left screen, then press "f" to get it into fullscreen mode and voila, it extends partially into the right screen covering the windows on that screen by a few pixels: 2*borderwidth to be precise. Here's what I think happens based on some digging through the xmonad code that I did: 1. xine goes into fullscreen and requests the full screen size as its geometry. 2. Since my manage hook floats xine, the xmonad floating window code kicks in, which honours the size request of the window but adds twice the border width to its size to accommodate the border decoration. 3. If I activate a layout modifier that removes the border on fullscreen float windows, then the border is removed but the geometry stays at the increased size. I didn't actually verify that this is what happens, but it's the most plausible explanation given the following observations I made: 1. the floatLocation function in XMonad.Operations adds 2*borderwidth to the size of the window as stated above. 2. the problem disappears with a border width of 0. 3. xine extends into the right screen by 2*borderwidth no matter whether I remove borders from fullscreen float windows or not. 4. Changing the layout so that the screens are arranged vertically and placing xine onto the top screen, it extends by 2*borderwidth into the bottom screen. 5. the problem does not appear in any other environment I tried (gnome, kde, awesome), presumably because they automatically remove the border from fullscreen windows without adjusting their geometry. Maybe xine even sets a window hint that says it doesn't want a border, and those window managers honour this request while xmonad does not? So my question for the list is what can be done to fix this behaviour. In my opinion it boils down to the question of whether adding the borderwidth to the window geometry as X.O.floatLocation does is the right thing to do. I think it is for windows that are not fullscreen, but for windows that are fullscreen it is more likely than not that it isn't. Would it make sense for X.O.floatLocation to distinguish between windows that take up the full size of a screen and ones that do not and treat them differently? - Norbert

2 1

Issue 431 in xmonad: floating windows' border widths are computed at the wrong time
by codesite-noreply＠google.com 08 Feb '11

08 Feb '11

Status: New Owner: ---- New issue 431 by allber...(a)gmail.com: floating windows' border widths are computed at the wrong time http://code.google.com/p/xmonad/issues/detail?id=431 What steps will reproduce the problem? 1. Float a window full-creen (that is, use doFullFloat in a ManageHook). It actually always occurs but is most obvious when a floating window is made significantly larger than its requested size. What is the expected output? What do you see instead? It should be made full screen, without a border if noBorders/smartBorders/etc. is in effect. But what happens is the width of the border is added to the window size before it is scaled to fit the parcel xmonad gives it (see XMonad/Operations.hs, function "windows", where the border is added in early but the scaleRationalRect of floating windows is done late; hence the border reservation is *also* scaled). What version of the product are you using? On what operating system? xmonad 0.9.1, 0.9.2, and darcs; problem has been observed on multiple Linux versions and is OS-agnostic. Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". Please provide any additional information below. First mentioned http://www.haskell.org/pipermail/xmonad/2011-January/010960.html

1 0