- xmonad - Haskell.org

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...@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 09 Feb '11

09 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...@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

Issue 430 in xmonad: KDE special window management mishaps
by codesite-noreply＠google.com 08 Feb '11

08 Feb '11

Status: New Owner: ---- New issue 430 by plc...@gmail.com: KDE special window management mishaps http://code.google.com/p/xmonad/issues/detail?id=430 In KDE, plasma dropdown windows (such as the k-menu and the systray extender) behave like regular windows, and thus they tile. However, they should float ideally. Similarly, krunner is managed like a dock and is thus unable to receive keyboald input apparently, rendering it pretty useless. I have made a small fix in my xmonad.hs config, but I really think that this should be the default behaviour kde4Config. Attachments: xmonad.hs 606 bytes

1 4

how to log out of xmonad?
by Brendan Miller 08 Feb '11

08 Feb '11

I just installed xmonad for the first time today, considering switching to it from gnome. I'm logged into an xmonad session. How do I log out of xmonad and get back to GDM?

4 3

prevent stalone tray from overlapping
by Brendan Miller 07 Feb '11

07 Feb '11

I'm setting up xmonad for the first time. I've setup stalonetray to hold nm-applet. I start both in my .xinitrc. Right now stalonetray overlaps my other windows. Is there some way to give trays a dedicated section at the top of the screen? I was reading online that something called "struts hints" are supposed to do that. Supposedly stalonetray supports these; however, it still ends up overlapping. Do I need to do some xmonad configuration to get it to recognize that stalone tray wants its own section of the screen? Right now I'm mostly just using the default xmonad config. The other issue I'm running into is that as I switch focus between windows using mod-j mod-k, stalonetray also receives focus. I'd rather focus skipped over stalonetray. Is there someway to tell xmonad to not focus a particular window with mod-j and mod-k? Thanks, Brendan

2 1

updating.... in xmobar
by Jacob Alexandersson 04 Feb '11

04 Feb '11

Hey all, I just started trying xmonad out, and I really ilke it. I've used ratpoison in the past but eventually gave it up. xmonad seems to work better for me so far. I realize this is a xmobar question, but I am guessing there are people on this list that uses xmobar also. I have a .xmobarrc which looks like follows: <snip> Config { font = "-*-Fixed-Bold-R-Normal-*-13-*-*-*-*-*-*-*" , bgColor = "black" , fgColor = "grey" , position = TopW L 100 , lowerOnStart = True , commands = [ Run Cpu ["-L","3","-H","50","--normal","green","--high","red"] 10 , Run Memory ["-t","Mem: <usedratio>%"] 10 , Run Swap [] 10 , Run Date "%a %b %_d %l:%M" "date" 10 , Run Com "uname" ["-s","-r"] "blaj" 36000 , Run StdinReader ] , sepChar = "%" , alignSep = "}{" , template = "%StdinReader% }{ %blaj% %cpu% | %memory% * %swap% <fc=#ee9a00>%date%</fc>" } </snip> ...and in ~/.xmonad/xmonad.hs I have: <snip> ... xmproc <- spawnPipe "/usr/bin/xmobar /home/jcx/.xmobarrc" ... </snip> All I get is "updating..." where %StdinReader% is placed. Is this correct?? Am I missing something? cheers, Jacob.

3 3

Issue 427 in xmonad: xmonad should recompile configuration on SIGHUP
by codesite-noreply＠google.com 04 Feb '11

04 Feb '11

Status: New Owner: ---- New issue 427 by moreil...@gmail.com: xmonad should recompile configuration on SIGHUP http://code.google.com/p/xmonad/issues/detail?id=427 in unix it's common convention for long-lived processes to re-read configuration and restart on receiving a HUP signal. to my surprise xmonad does not follows this.

1 3