February 2008 - xmonad

darcs patch: add --help option
by Lukas Mai 25 Mar '08

25 Mar '08

Wed Jan 30 00:52:58 CET 2008 Lukas Mai <l.mai(a)web.de> * add --help option

2 1

Newbie: Problems with Layouts and Syntax
by john spencer 15 Mar '08

15 Mar '08

Hi! After having some contact with xmonad 0.4 (and dismissing it for some reasons) I thought it's time to have a look at it again. And ... wow! :-)) Maybe it's now time to change - if I can get some things right. I'm currently a user of larswm; I configured it to have one large main (master) area and all the other windows of the current workspace stacked on the right site. With that configuration I am very fast selecting the window I want and making it the 'master'. I never work in one of the windows on the right site (you could also work in fullscreen mode -I hear you say- but for me its much more convenient to know in ONE look how many times I have to hit the 'next window' key than checking it every time I switch fullscreen); this means that these windows are never resized (just once when they are created at the main area). Long speech - short sense: I need a fast possibility to select the window I am interested in. As I can see, I have several possibilities with xmonad: 1. I could use the Hinted Tile Layout. As far as I understood, this layout shouldn't resize the windows when they are put out of the master. This would be the same configuration as I use currently with larswm. The problem is, it doesn't work always. Some apps (ie. aterm, konsole) seem to get resized which results in a nearly blank window when getting them back to the master. I don't know why the behaviour in larswm is different here - any ideas? 2. I could use the Tabbed Layout. Unfortunately the tabs currently are not giving me a really fast glue what is behind them. I have to read the title of the tabs - thats not very fast. I can image that some color-coding (ie. using regexps in the config) could improve this significantly. Also -since working on the terminal means looking at the bottom of the screen most of the time- putting the tabs at the bottom instead of the top would also be a great enhancement. What do you think? Are there any other options you can think of? Unfortunately I don't have any progamming skills w/ haskell. Which brings me to another problem: I'd like to map a key to execute two actions: I want to execute "windows W.focusDown" followed by a "windows W.swapMaster"; I have no idea how to specify this: ((modMask .|. shiftMask, xK_Return), ... ??? ... -- windows W.focusDown && windows W.swapMaster Could somebody help me with this? Thanks! - john -- chris

6 14

my proposal for a Xinerama safe PerWorkspace
by Andrea Rossato 09 Mar '08

09 Mar '08

Hi, this is my proposal for a Xinerama safe PerWorkspace. It includes a new LayoutClass method: runLayout :: Workspace WorkspaceId (layout a) a -> Rectangle -> X ([(a, Rectangle)], Maybe (layout a)) This is just some code moved around: Fri Feb 22 18:58:15 CET 2008 Andrea Rossato <andrea.rossato(a)unibz.it> * runLayout is now a LayoutClass method and takes the Workspace and the screen Rectangle M ./XMonad/Core.hs -7 +7 M ./XMonad/Operations.hs -5 +5 This is the patch to PerWorkspace: Fri Feb 22 18:59:54 CET 2008 Andrea Rossato <andrea.rossato(a)unibz.it> * PerWorkspace: reimplemented using runLayout This way we have a Xinerama safe PerWorkspace and the emptyLayout method for free. M ./XMonad/Layout/PerWorkspace.hs -73 +27 Some lines were left there just because I'm lazy....;) Cheers, Andrea ps: I must confess that if the runLayout method could be accepted in the core my request of changing the 'description' type would be gone. While my sense of symmetry would require it for implementing a LayoutCombinator class as I have it mind, still I'm coming to thing that, from the practical point of view, the restrictions imposed by that signature are irrelevant for our purposes. And, probably, the fact of restricting the class to what I call pure combinators only, would be just fine. This is quite a common pattern of mine when it comes to type classes: I cannot see where I'll end up when I start implementing them. There must be some hidden weirdness I cannot grasp entirely. ;)

5 7

Removing Actions.WmiiAction in favor of Prompt.DirExec
by Juraj Hercek 05 Mar '08

05 Mar '08

Hello, I've written Prompt.DirExec which implements basically the same functionality like Actions.WmiiActions but uses Prompt instead of dmenu . I plan to purge Actions.WmiiActions from contrib and add Prompt.DirExec. I consider DirExec better than WmiiActions because it doesn't depend on dmenu (which needs patch for xinerama to work properly anyways). I like Prompt better - it's part of contrib and handles xinerama "automagically". If anyone objects against removal of Actions.WmiiActions, please let me know. If there are no objections, I'll send a removal patch soon. Cheers, Juraj PS: Is there any plan to get rid of dmenu completely?

2 4

ScratchWorkspace
by David Roundy 04 Mar '08

04 Mar '08

I've just pushed in a ScratchWorkspace module that defines a scratch workspace. You can look at Config.Droundy to get an idea how to use it (as it's undocumented). It's still very crude, and anyone who wants to take a shot at cleaning it up is welcome to try. The main issue is that the scratch workspace is available as a "normal" workspace, which I find a little annoying. I'd prefer it remained hidden until I asked for it. But I can't quite see how to do that, either. Enjoy! (and comments/suggestions are welcome, although I've really already wasted more time on this than I ought...) -- David Roundy Department of Physics Oregon State University

2 4

Pointer follows focus (with patch)
by Robert 04 Mar '08

04 Mar '08

I sometimes get annoyed at having to get my mouse from several screens over to my current window to click on things I'm working on. I hacked around this by binding a key to Warp.warpToWindow but I'm starting to think there should be the following invariant: the pointer should always be over the focused window. So not only does the focused window follow the pointer as it does now, but the pointer will also follow any window focus.Using the Warp module I got this close to working in my config file. I had lots of keybindings which are modified to look like this: windows W.swapUp >> warpToWindow (1%2) (1%2) What prevents me from getting the invariant I'm aiming for is new or destroyed windows. By adding a new warpToWindow function which takes a window to warp to, and using a ManageHook I got quite close to getting it working for new windows. I had something that looked like this: manageWarp = ask >>= \w -> liftX (warpToWindow w (1%2) (1%2)) >> doF id It worked great for floating windows but not for tiled windows. I think the reason is because the hook management code is done before the layout code, so the pointer just warps to wherever the window asks to be put which becomes wrong as soon as xmonad puts the window into it's proper location. So anyway, I'm starting to think this isn't going to be possible to do in my config. But I think it's possibly closer to the right way to handle the pointer than what exists now. I've included a patch which adds support for a mouseFocusWarpPos config flag to XMonad. It's disabled by default but that could be changed if others like it. Currently it moves the mouse pointer to a relative position within the window the user configures. I'm not entirely happy with this. What might be better is for each window to keep track of where the mouse was and go back there whenever the window regains focus. But that may be too complicated. Feedback appreciated.

4 10

Invisible cursor with XFT font in Prompt
by lithis 04 Mar '08

04 Mar '08

I recently enabled XFT support in XMonadContrib. When using a TrueType font, the cursor in prompts is invisible. It seems to be printing the character under the cursor with bgColor as both the forground and background (I was able to see the the edge of an “f” under the cursor overwriting the edge of a preceeding “d”, so I know that it is being drawn). Also, the visual length of the string changes as the cursor moves. While scrolling through the string, the portion after the cursor wiggles left and right by a few pixels. When the cursor reaches the beginning of the line, the length shortens much more.

2 1

Proposal: Advanced Scratchpad-Features
by Dominik Bruhn 01 Mar '08

01 Mar '08

Hy, I recently found the Scratchpad on the Mailinglist (thanks, Braden for this). But, im missing two features: 1. Is it possible to hide the scratchpad (not close, only hide) with the same hotkey? So if I press the Hotkey once the scratchpad apears and another hit it disapears and I can recall it with the same hotkey. 2. Can the scratchpad made visible on all workspaces? So if I switch my workspace it stays visilbe and I can recall (with 1.) the same scratchpad everywhere? The reason for this is: I want to start a musicplayer (mocp or something like this) in the scratchpad and want to view it on every workspace im on. Is this possible? Thanks -- Dominik Bruhn mailto: dominik(a)dbruhn.de

7 8

Issue 143 in xmonad: XEvent hook or similar needed
by codesite-noreply＠google.com 29 Feb '08

29 Feb '08

Issue 143: XEvent hook or similar needed http://code.google.com/p/xmonad/issues/detail?id=143 Comment #10 by Braden.Shepherdson: Part of the question is speed; if every event gets run through a list of such handlers, it seems like the majority of the events will end up back in the hands of Main's handle function. I don't know how frequently events arrive. Maybe use pattern matching? Rename the existing handle to handle', the new handle tries the user's messageHook (:: Event -> X Bool, pattern matching like handle but indicating whether handle' should still process the event), and if the response is False, try it with handle'. I'm not sure how pattern matching would compare speed-wise with a list. It also enforces only one handler per event, which I think might be desirable. Whatever solution is settled on, I think it's desirable to have type -> X Bool, so the user's message handlers can either eat the event, or leave it to be processed as normal. That opens up the ability for extensions to observe events without consuming them. And as a use case other than EWMH: timers. The current Util.Timer module only works for LayoutModifiers, because only they can handleMessage right now. Instead, this module could just offer a handleTimer to use in messageHook, and then we have general-purpose timers. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

Issue 57 in xmonad: Amarok OSD goes missing
by codesite-noreply＠google.com 29 Feb '08

29 Feb '08

Issue 57: Amarok OSD goes missing http://code.google.com/p/xmonad/issues/detail?id=57 Comment #2 by spo...@cs.cmu.edu: According to xprop, the Amarok OSD has _NET_WM_STATE(ATOM) = _NET_WM_STATE_ABOVE, _NET_WM_STATE_STAYS_ON_TOP WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING Does XMonad support extended hints like ABOVE? FWIW, I've also seen a similar behavior when using KDE's Katapult (http://katapult.kde.org/) with XMonad. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0