June 2012 - xmonad - Haskell.org

shellPrompt dmenu like completion
by Carsten Mattner 23 Jun '12

23 Jun '12

Prompt.Shell's shellPrompt function works well except that I couldn't make it auto-select the first entry of the possible completions. If it did that, it would be a perfect dmenu replacement. xmonad and xmonad-contrib both are at 0.10. Haven't configured any non-default behavioral XPConfig settings.

2 2

dwm like resizeHints
by Carsten Mattner 22 Jun '12

22 Jun '12

I'd like to not ignore resize hints same as dwm's default of resizeHints=True. Is this possible with any of the layout extensions?

2 2

focus history
by Konstantin Sobolev 22 Jun '12

22 Jun '12

Hi if anyone's interested: attached is my alt-tab implementation, I saw it being requested a couple of times. Unlike CycleWindows keeps track of the focus globally, not per-workspace.

1 0

Problem with xmonad and rendering Dolphin windows in KDE
by Leo Alekseyev 22 Jun '12

22 Jun '12

I recently made the switch to KDE (Kubuntu 12.04, to be precise); xmonad works very well with it, except for one thing: Dolphin windows take a rather long time to render compared to other applications. By that I mean that if I switch to a desktop which has Dolphin windows visible, the Dolphin windows will show as grey background for about 2-3 seconds, before being rendered properly. Right afterwards, switching between the "Dolphin" desktop and another desktop is rather fast (Dolphin renders quickly). But if I stay on a different desktop for more than about 1 minute and then switch back to the "Dolphin" desktop, I'll see the 2-3 second delay again. This behavior seems exclusive to Dolphin (other Qt apps and GTK apps seem to work fine). If other KDE users on the list have seen this behavior and/or can suggest any remedies, I would be interested in hearing about it! --Leo

1 0

Issue 510 in xmonad: Documentation for XMonad.Layout.Fullscreen uses obsolete eventHook name
by codesite-noreply＠google.com 18 Jun '12

18 Jun '12

Status: New Owner: ---- New issue 510 by pajmullaney: Documentation for XMonad.Layout.Fullscreen uses obsolete eventHook name http://code.google.com/p/xmonad/issues/detail?id=510 The examples in the documentation for XMonad.Layout.Fullscreen [1] use the obsolete "eventHook" instead of the new "handleEventHook". If the example configuration is used without making that change, it results in a compile error. [1] - http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Layout-Fullscreen.html

1 1

Changing configuration depending on the context
by Pablo Olmos de Aguilera Corradini 18 Jun '12

18 Jun '12

I'm sorry if the title is misleading, I just don't know how to explain it in one sentence. Normally I use my xmonad system in two contexts, one in my laptop (1366*768) and in my "workstation" that consists in a 21" monitor (1980*1280) as primary monitor and with the laptop as secondary. This leads me to not being able to use the same configuration every time. I've been trying a lot of stuff to put the dzen|tray|conky bars according to the dimension using the libraries from haskell, but sometimes they doesn't work as expected overlapping bars, mostly because when xmonad just starts there is one screen cloned in both monitors, then I have to start my xrandr script to fix the dimensions and position of both. My actual approach consists to call a do block from the main block of the xmonad.hs file, and then a lot of local variables (using 'let') from the function that is getting the screen dimensions, with them I was trying to do some math and include them on dzen, the tray application, ecc. I'm still learning haskell and xmonad, so probably I'm not using the best approach. Any suggestion Regards! -- Pablo Olmos de Aguilera Corradini - @PaBLoX http://www.glatelier.org/ http://about.me/pablox/ http://www.linkedin.com/in/pablooda/ Linux User: #456971 - http://counter.li.org/

2 1

Remove outside borders from windows
by Zach Hirsch 16 Jun '12

16 Jun '12

Hi, [Trying this again since my first post didn't seem to go through. Apologies if you get this twice.] I just started using xmonad, and it's pretty great. One usability issue that I've run into is that the tabs in Google Chrome aren't quite at the top of the screen, i.e. I can move the mouse to the top of the screen and click on a tab. This seems to be due to the window borders; using NoBorders fixes this, but it also removes the borders _between_ windows, which I don't want. Is there some way to remove just the outside borders? Thanks, -Zach

3 4

Issue 508 in xmonad: The UpdatePointer action doesn't support XFCE multihead
by codesite-noreply＠google.com 12 Jun '12

12 Jun '12

Status: New Owner: ---- New issue 508 by vox.cogi...(a)gmail.com: The UpdatePointer action doesn't support XFCE multihead http://code.google.com/p/xmonad/issues/detail?id=508 1. Start xmonad in XFCE as directed through the guide on the xmonad homepage. System must have at least two monitors. 2. Open a window on main monitor. 3. Switch focus to second monitor, using Alt-E. 4. Switch focus back to main monitor, using Alt-W. One would expect the mouse cursor to start in monitor 1, go to monitor 2 and then back to monitor 1. What actually happens is that the final step isn't executed, so that the cursor remains on the empty monitor. If there is also a window open on the off monitor, the bug doesn't occur. I'm using xmonad 0.10-3 on Arch Linux. I've attached my main xmonad.hs file, as well as a simplified file which exhibits the same bug. Neither of them have any output when fed to xmonad --recompile. Attachments: xmonad-simplified.hs 142 bytes xmonad.hs 1.3 KB

1 1

Re: [xmonad] Changes to XPrompt
by Carlos López Camey 06 Jun '12

06 Jun '12

2012/5/7 Carlos López Camey <c.lopez(a)kmels.net>: > 2012/5/6 <wagnerdm(a)seas.upenn.edu>: >> Hello Carlos! >> >> >> Quoting Carlos López Camey <c.lopez(a)kmels.net>: >> >>> The changes would be: >>> * Autocomplete based on several modes (there is always a mode set) >>> The autocomplete items are generally path to files, mode 1 >>> could use for example `locate %s`, mode 2 `recollq` [0] (searches for >>> tokens inside files) and mode 3 `locate --regexp %s` to autocomplete. >> >> >> mkXPrompt already seems to allow you to specify an IO action to run to >> create your list of completions. That IO action can itself do any of the >> things you name, so I don't think you should need to make any changes to >> realize this wish. >> >> >>> * one-column-only list of autocompletions >>> For the purpose, they are always paths, so they are quite >>> large to keep it in different columns. But this be a setting on the >>> configuration. >>> >>> * Navigating through completion items and changing autocompletion >>> list on "real time" >>> There is always an item highlighted (if items > 0) >>> The highlighted item not necesarilly is equal to the >>> prompt buffer text. I may write "xmonad.hs" but the autocomplete item >>> shows a full path highlighted. This implies adding an additional field to >>> XPState, complIndex :: Int, that knows which item to highlight next (not >>> based on the buffer's text) >> >> >> I'm not an XPrompt user, so I can't comment on whether these are possible or >> not right now, but if not, they sound like nice things to add. >> >> >>> * Action is not necesarilly a String -> X a. >>> >>> I'd like to count on a Map Extension (String -> String) in some >>> config, where type Extension = String. This map would describe what to >>> do with each file depending on its extension. e.g. an element of the >>> map could be (".org",\path -> "emacs "++path). So I'm not sure how the >>> new signature would be: String -> X a? but this String would be the >>> command sent to spawn, computed using a function that uses the map >>> described above. >> >> >> You may accomplish this by having your String -> X a function close over the >> Map you want to query; for example, something like this: >> >> fConstantMap :: String -> X a >> fConstantMap s = case lookup constMap (extension s) of >> Nothing -> spawn s >> Just modifier -> spawn (modifier s) >> where >> extension = reverse . take 4 . reverse >> constMap = fromList [ >> (".org", \path -> "emacs " ++ path), >> (".doc", \path -> "libreoffice " ++ path) >> ] >> >> or, if the Map is going to be built dynamically rather than known at compile >> time, you can have the map be an argument to the function and pass the >> function partially-applied to mkXPrompt[WithReturn]. >> >> Good luck, and I hope this helps with half your requests! >> ~d >> > Greetings again, I forgot to copy the list earlier! > Hello, thanks for the help! After reading your comments, I think it is > possible to make the changes to XPrompt. Modifications to XPrompt, > XPState and XPConfig shouldn't have to break configs (default settings > would have to be added to defaultXPConfig, as well as default > definitions for possible new functions on XPrompt). > > Back to it then. > Carlos I've coded a bit more, and I think that if different modes are to be added *and* backwards _api compatibility_ is to be kept, it is necessary to include either Data.Typeable or Data.Proxy according to [0]. Correct me if I'm wrong but we can't reify *any* function with Typeable? With Data.Proxy it is possible but xmonad-contrib would need package `tagged` as a dependency. There is a way to keep backwards compatibility to xmonad.hs files but not to modules that use XPrompt. They (XMonad/Prompt/*.hs and XMonad/Actions/Search.hs) must include an instance of XPMode and provide it to mkPrompt, instead of both the explicit completion and action functions, i.e. replace mkXPrompt t conf compl action with mkXPrompt t conf myMode where myMode = XPMode { complFunction = .. action = .. } Would that be ok? I don't think many xmonad.hs use mkXPrompt directly. Carlos

2 3

Raise focused floating window ?
by David Unric 06 Jun '12

06 Jun '12

Hi, probably a simple question but how can I configure Xmonad to raise (ie. move to the top of the stack, in front of all windows) a floating window after it recieves a focus with the keyboard ? Trying to mimic Awesome's WM floating layout, window focused with <mod>+j or <mod>+k is raised above all other windows. Thanks. David

1 0