- xmonad - Haskell.org

KeyEvent stream manipulation
by Daniel 27 Sep '10

27 Sep '10

For what I want to do I need to have exclusive access to the keyboard events so that I can rewrite them. I have been experimenting a bit with this in XMonad, but passive grabs don't work. The problem with passive grabs is with overlapping events. This is what happens: * press key A * grab converts from passive to active * KeyEvent keyPress A is delivered to XMonad * B is pressed * KeyEvent keyPress B gets delivered to XMonad (B is registered as passive grab as well, but gets delivered, because technically, we're in an active grab now) * A is released * KeyEvent keyRelease A gets delivered to XMonad * active grab on A reverts to passive (incl some FocusEvents & KeymapNotify to inform us that B is still held) * B is released * KeyEvent keyRelease B gets NOT delivered to XMonad, it's a regular KeyEvent, no grab is active, and the passive grab on B is not triggered, because its keyPress event occurred during another (shadowing) activeGrab. (Actually, if you keep pressing B, after about a second or so, X realizes that there should be a grab active and enters the grab. Unfortunately, this is not fast enough when typing. Just to be clear, this is a problem of passive grabs, not with XMonad. Because of this behaviour it seems that the only thing that gets me there within X is a permanent active grab (keyboardGrab). Other extensions use active grabs, but they only do this for a limited time, usually after being triggered (eg. CycleRecentWS, Submap, GridHS, CycleWindows). So my questions: * Is such a permanent active grab a good idea within X? I'm worrying about problems interacting with other programs who might attempt grabs or XMonad losing the grab and not knowing about it. * If this is not a good idea, what should I look into to get this capability (exclusive access to transform the keyboard event stream, before it reaches any application). * Where/who should I ask to get an informed answer if not here? My end target are X applications, and I expect that there will be a tight integration with the window manager (likely XMonad). But I'm willing to look at a variety of points to hook into the event stream. Thanks

2 4

Issue 400 in xmonad: LayoutHints don't respect windows' hint changes without changing the workspace state
by codesite-noreply＠google.com 26 Sep '10

26 Sep '10

Status: New Owner: ---- New issue 400 by aleks.dimitrov: LayoutHints don't respect windows' hint changes without changing the workspace state http://code.google.com/p/xmonad/issues/detail?id=400 What steps will reproduce the problem? 1. Use a minimal configuration like: main = xmonad $ defaultConfig { layoutHook = layoutHints (XMonad.Tall 1 (1/2) (3/100)) } 2. Open Rhythmbox and press CTRL-D (to collapse the view to 'compact view') 3. Change the workspace state (toggle struts, change focus, launch stuff) What is the expected output? What do you see instead? I'd like XMonad to recognize Rhythmbox' state change without re-evaluation of the workspace state. XMonad however doesn't seem to be notified of Rhythmbox' preferred size, or maybe just doesn't react to it. Here's a couple of screenshots to illustrate the problem: http://imgur.com/THPdml&y5e0U&r6n58 First image shows what happens when RBX changes its appearance and XMonad doesn't react (these huge grey windows are exactly what I'm trying to avoid using hinted layouts.) Second image shows the desktop after a state change. That's what I'd like to see! Third image shows RBX expanding to its extended view again, but the window doesn't get bigger! It stays small and requires a workspace state change to go back to normal. What version of the product are you using? On what operating system? xmonad 0.9.1 (Ubuntu 10.04) Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". Minimal reproducing config: > import XMonad > import XMonad.Layout.LayoutHints > main = xmonad $ defaultConfig > { layoutHook = layoutHints (XMonad.Tall 1 (1/2) (3/100)) } xmonad --recompile remains silent :-)

1 5

Issue 398 in xmonad: Make Keyboard Keys Position Dependant not Value Dependant
by codesite-noreply＠google.com 26 Sep '10

26 Sep '10

Status: New Owner: ---- New issue 398 by robertmassaioli: Make Keyboard Keys Position Dependant not Value Dependant http://code.google.com/p/xmonad/issues/detail?id=398 Prenote: This is a wishlist item and not critical. What is the problem? The problem is that anybody that creates an xmonad.hs for qwerty, for example, excludes anybody else using a different keyboard layout. And vice versa. However, when I create my xmonad.hs I find that I often only care about keyboard position and not the actual letter that I am pressing. You should be able to make your keyboard layout by specifying keyboard positions rather than the actual keys themselves. What is the expected result? This would allow better sharing of XMonad config files between everyone. And for those that specify by position, like me, it would be easier and more portable. I don't know how much effort it would really be though, but maybe you could change something small about it to make it work for you. I have a dummy function in my xmonad.hs that I may start using for that sort of portability called 'convertKeys': http://github.com/robertmassaioli/xmonad.hs/blob/master/xmonad.hs

1 4

Issue 404 in xmonad: windowPromptGoto lists NSP windows
by codesite-noreply＠google.com 25 Sep '10

25 Sep '10

Status: New Owner: ---- New issue 404 by rpglover64: windowPromptGoto lists NSP windows http://code.google.com/p/xmonad/issues/detail?id=404 What steps will reproduce the problem? 1. Import and set up NamedScratchpad and windowPromptGoto 2. Open and hide the scratchpad window 3. Use windowPromptGoto What is the expected output? What do you see instead? A list of windows, not including those on the scratch space. A list of windows, including those on the scratch space. What version of the product are you using? On what operating system? xmonad 0.9.1 on debian testing Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". Recompile is clean Please provide any additional information below. This is really more of a feature request than a bug... Attachments: xmonad.hs 6.1 KB

1 1

darcs patch: X.H.ManageDocks: event hook to refresh on new docks
by Tomas Janousek 25 Sep '10

25 Sep '10

Dear xmonad, for all of you who restart all your xmobars every now and then (for example on xinerama layout change), this makes xmonad behave a bit better: > 1 patch for repository http://code.haskell.org/XMonadContrib: > > Tue Jul 6 20:58:34 CEST 2010 Tomas Janousek <tomi(a)nomi.cz> > * X.H.ManageDocks: event hook to refresh on new docks -- Tomáš Janoušek, a.k.a. Liskni_si, http://work.lisk.in/

3 2

Issue 407 in xmonad: Resizing a size-hinted window very small yields bad dimensions
by codesite-noreply＠google.com 25 Sep '10

25 Sep '10

Status: New Owner: ---- New issue 407 by djpohly: Resizing a size-hinted window very small yields bad dimensions http://code.google.com/p/xmonad/issues/detail?id=407 What steps will reproduce the problem? 1. Set XSizeHints on a window for PResizeInc and PBaseSize. 2. Resize (Mod-right-drag) this window to a size which is smaller than the base size. What is the expected output? What do you see instead? For certain combinations of base size and resize increment--bs=(4,4) and inc=(7,15) is known to work--the window receives an XConfigureEvent with an obviously overflown dimension (in the 65535 region) when resized down. What version of the product are you using? On what operating system? XMonad-darcs-20100902 on Linux, GHC 6.12.3 Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". Don't think this is relevant (see below) but if you want it, ask for it. Please provide any additional information below. The problem appears to be line 549 of Operations.hs: . maybe id (\(bw,bh) (w,h) -> (w-bw, h-bh)) (sh_base_size sh) In the subtraction in this line, all four operands are ::Dimension, an unsigned type. The problem occurs when XMonad subtracts the base size, resulting in large integers, then rounds them down according to the resize increment. If the subtraction were performed on Integrals instead of Dimensions, the problem would be fixed. The attached patch appears to fix the bug. I'm neither an XMonad nor a Haskell expert, so this is likely not the best way to do it, but it can at least illuminate where the problem lies. :) Attachments: xmonad-resize.patch 1.4 KB

1 1

Issue 395 in xmonad: Support for multiple master windows for X.L.Master
by codesite-noreply＠google.com 25 Sep '10

25 Sep '10

Status: New Owner: ---- New issue 395 by quesel: Support for multiple master windows for X.L.Master http://code.google.com/p/xmonad/issues/detail?id=395 Find attached a patch that enables the contrib module X.L.Master to handle multiple master windows. Best Regards, Jan Attachments: master.patch 42.6 KB

1 4

Shift windows around
by Tony Morris 25 Sep '10

25 Sep '10

Hello, I have 0 or more windows with a specific class name and I'd like to move each to its own workspace. Is this possible? -- Tony Morris http://tmorris.net/

5 6

cannot build xmonad-contriib from darcs
by Sergey Manucharian 25 Sep '10

25 Sep '10

Hi folks, I'm not a haskell programmer but I succesfully built xmonaf-contrib from darcs many times. Today it does not work: ------------------------------8<------------------------------- Configuring xmonad-contrib-0.9.1... Preprocessing library xmonad-contrib-0.9.1... Building xmonad-contrib-0.9.1... [ 85 of 208] Compiling XMonad.Util.Image ( XMonad/Util/Image.hs, dist/build/XMonad/Util/Image.o ) XMonad/Util/Image.hs:24:39: Module `XMonad.Util.Font' does not export `fi' ------------------------------8<------------------------------- Any ideas? Cheers, Sergey

3 2

sh-less spawn?
by Joachim Breitner 21 Sep '10

21 Sep '10

Hi, I just noticed this in my process list: │ ├─xmonad-x86_64-l │ │ └─sh -c gnome-terminal │ │ └─gnome-terminal and the reason is here, in Core.hs: -- | Like 'spawn', but returns the 'ProcessID' of the launched application spawnPID :: MonadIO m => String -> m ProcessID spawnPID x = io . forkProcess . finally nullStdin $ do uninstallSignalHandlers createSession executeFile "/bin/sh" False ["-c", x] Nothing where nullStdin = do fd <- openFd "/dev/null" ReadOnly Nothing defaultFileFlags dupTo fd stdInput closeFd fd Generally, this is of course useful. But I bet that most commands passed to spawn are simple program names without arguments or any fancy shell-related stuff. Executing a shell here seems overkill. Not much, but still avoidable. How about checking whether the argument x contains only alphanumerical characters and, if that is the case, executing the program directly? Such short-circuit logic is for example also used by perl’s sytem(), see perldoc -f system: If there is only one scalar argument, the argument is checked for shell metacharacters, and if there are any, the entire argument is passed to the system's command shell for parsing (this is "/bin/sh -c" on Unix platforms, but varies on other platforms). If there are no shell metacharacters in the argument, it is split into words and passed directly to "execvp", which is more efficient. Greetings, Joachim -- 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 3