May 2009 - xmonad - Haskell.org

Issue 293 in xmonad: ~/.xmonad/ not in include path
by codesite-noreply＠google.com 07 May '09

07 May '09

Updates: Status: Duplicate Mergedinto: 230 Comment #1 on issue 293 by SpencerJanssen: ~/.xmonad/ not in include path http://code.google.com/p/xmonad/issues/detail?id=293 (No comment was entered for this change.) -- 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 294 in xmonad: fadeInactiveLogHook behaviour messed up on xinerama
by codesite-noreply＠google.com 06 May '09

06 May '09

Status: New Owner: ---- New issue 294 by kernseife: fadeInactiveLogHook behaviour messed up on xinerama http://code.google.com/p/xmonad/issues/detail?id=294 0.8 fadeInactiveLogHook keeps one window per screen opaque, not only the focused window of the active screen. Related: There are some apps that some user might not want to have faded, like mplayer. Suggestion: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=4670 ...or, rather, fadeInactiveLogHook :: Ratio -> [Query Bool] -> X () -- 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 293 in xmonad: ~/.xmonad/ not in include path
by codesite-noreply＠google.com 06 May '09

06 May '09

Status: New Owner: ---- New issue 293 by kernseife: ~/.xmonad/ not in include path http://code.google.com/p/xmonad/issues/detail?id=293 Currently, xmonad explicitly nukes the include path when it compiles itself. Having ~/.xmonad/ in it would make source management less messy. Potential naming issues ("import XMonad" being recursively resolved to xmodad.hs instead to the library on case-insensitive file systems) can be worked around with by renaming xmonad.hs -- 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 292 in xmonad: Border pixels not rendered on screens rotated with xrandr
by codesite-noreply＠google.com 06 May '09

06 May '09

Status: New Owner: ---- New issue 292 by david.jc.anderson: Border pixels not rendered on screens rotated with xrandr http://code.google.com/p/xmonad/issues/detail?id=292 What steps will reproduce the problem? 1. Start xmonad with a config that sets a border around the active window 2. Create a couple of windows, note the border being rendered 3. Run `xrandr -o left` to rotate the display to portrait mode After screen rotation, the pixels usually used to render the border are no longer rendered. The focused window does not have a highlighted border around it. Space for the border is still reserved (tested by grabbing a 50 pixel border), but apparently not rendered into by xmonad. The contents of the border pixels varies from black, to partially drawn highlight color around a random window (not always the focused one), to framebuffer noise. Executing `xrandr -o normal` returns to the previous configuration, with the border correctly rendered. What version of the product are you using? On what operating system? Ubuntu 9.04 xmonad 0.8.1 X.org 7.4 My xmonad.hs is attached. `xmonad --recompile` outputs nothing. Random musings: it has been suggested on #xmonad that this could be a video driver bug. Not knowing much about the ins and outs of the interactions between xmonad, X11 and the video driver, I cannot comment on this from a technical standpoint, but it seems strange to me that a video driver bug would cause exactly these border regions, and only them, to be borked, and that every other WM I've used on this setup somehow manages to avoid this problem. Not very scientific, I'm sure WM gurus will have a more useful opinion. I remain at your disposal if extra data or testing is required. Attachments: xmonad.hs 1.1 KB -- 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

Re: [xmonad] submapDefault patch - default action for submaps
by Anders Engström 06 May '09

06 May '09

Hello Stacey and the list since this includes a patch. I could not reproduce the behaviour, but I can clearly see where it fits in. The problem for me is that I cannot currently change the repeat rate (because of a bug in evdev) and my repeat rate is obviously too low for the bug to appear, but that is another issue. The problem is as you stated that ungrab-grab is run between key presses, so I moved the ungrab till after the selected command has been run. This should result in "grab new"-"ungrab old" behaviour and fix your problem, I think, but I haven't actually reproduced the bug so please check if this works and report the success or failure. It all seems to work for me, but I would like some feedback from someone a little bit more experienced than me since I'm rather new to haskell and xmonad myself. First question: It is okay to run grabKeyboard in a nested way like this, right? Second question: I dunno, is it just me, or is grabKeyboard/ungrabKeyboard not defined ANYWHERE? It must come from somewhere... But I could not find it when I tried to follow the import chain. /Anders Engström 2009/4/26 Stacey Sheldon <stac(a)solidgoldbomb.org>: > I'm trying to use the submapDefault functionality that you contributed > to XMonad, and I'm running into a small problem with it. Any assistance > that you can offer on this would be very much appreciated. If there are > any additional details that you require, I'd be happy to provide them. > > [Goal] > > I want to trigger a sticky submap, and then be able to move a floating > window around with the arrow keys. When I hit enter or escape, I want > to return to the normal keybindings. The basic functionality works as > expected so I think I've got the various moving parts connected properly. > > [Problem] > > When I use the arrow keys to move the windows around, I typically hold > down the arrow key until the window ends up in the right position. I've > noticed that some of the repeats of the arrow key are leaking through to > the focused window rather than being captured by the submap. This is > especially noticeable if I switch to using vi keys (h,j,k,l) rather than > the arrow keys to push the floating windows around. I then get a string > of these leaked h's in the focused window. > > I suspect this is caused by the ungrabKeyboard that (I think) happens > between handling one keypress and handling the next (repeating) one. If > the ungrab only occurred once the "exit" key had been pressed, maybe > this problem would go away. > > I'm not a complete haskell noob but I still don't quite have a handle on > how monads work. I have no idea how to fix this. > > [Context] > > I'm fairly certain that the issue that I'm seeing is unrelated to the > particular versions that I'm using but I'll give you the context anyway. > I'm using XMonad 0.8-1 on Ubuntu Intrepid (8.10) as the base > version. I've pulled the definition for submapDefault from the latest > darcs revision into my xmonad.hs file since your patch isn't in the > ubuntu release. > > I'm using submapDefault like this in my xmonad.hs file: > > entersub = submapDefault entersub sublist > sublist = M.fromList $ > [ -- Window floating stuff > ((0, xK_Return), return ()) > , ((0, xK_Escape), return ()) > , ((0, xK_t ), withFocused $ windows . W.sink) > , ((0, xK_Left ), (withFocused > (keysMoveWindow (-20,0))) >> entersub) > , ((0, xK_Right ), (withFocused > (keysMoveWindow (20,0))) >> entersub) > , ((0, xK_Up ), (withFocused > (keysMoveWindow (0,-20))) >> entersub) > , ((0, xK_Down ), (withFocused > (keysMoveWindow (0,20))) >> entersub) > ] > > If you've got the time to look at this, I'd be happy to try any > suggestions for how to fix this. > > Thanks. > > Stacey. >

3 2

darcs patch: NS_Placement (and 1 more)
by konstantin.sobolev＠gmail.com 05 May '09

05 May '09

Tue Apr 28 15:27:31 EDT 2009 konstantin.sobolev(a)gmail.com * NS_Placement Added ability to specify scratchpad manage hooks, mostly for defining window placement in a more flexible manner Tue Apr 28 16:01:36 EDT 2009 konstantin.sobolev(a)gmail.com * ScratchpadRewrite Scratchpad reimplementation in terms of NamedScratchpad. No interface changes.

4 4

Issue 290 in xmonad: Windows are no longer visible but are still there
by codesite-noreply＠google.com 05 May '09

05 May '09

Updates: Labels: Component-Contrib Comment #5 on issue 290 by nomeata: Windows are no longer visible but are still there http://code.google.com/p/xmonad/issues/detail?id=290 Zack writes at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526106: I've been working with no FadeInactive extension for a week now, and the problem disappeared. So it is most likely related to that extension, and I'm therefore reassigning the bug to the xmonad-contrib package. Looks like FadeInactive sets in some moment a complete fading or something, and then forgets about restoring it to a sane value which makes the window readable. It's too bad, because FadeInactive is very useful to recognize focused window. Actually, the problem might also be related to the xcompmgr compositing manager which I'm using. But I've no idea of which other manager I could try out to verify that or not. Suggestions are welcome on that point. -- 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

EZConfig changes for Util.NamedActions
by vogt.adam＠gmail.com 05 May '09

05 May '09

Hello To allow Util.NamedActions to be used with EZConfig, I had to generalize some type signatures in EZConfig and add an additional function. What do you think of these changes, should I go ahead and apply them? Thanks, Adam

4 3

Issue 291 in xmonad: Layout.Tabbed has drawing problems when used with Layout.MultiToggle
by codesite-noreply＠google.com 04 May '09

04 May '09

Status: New Owner: ---- New issue 291 by lsoksane: Layout.Tabbed has drawing problems when used with Layout.MultiToggle http://code.google.com/p/xmonad/issues/detail?id=291 What steps will reproduce the problem? 1. Toggle Tabbed layout on with MultiToggle 2. Open a new window or close a window What is the expected output? What do you see instead? Names of tabs are not drawn correctly i.e. some of the names are missing. What version of the product are you using? On what operating system? xmonad-darcs-20090501-1-x86_64 xmonad-contrib-darcs-20090503-1-x86_64 (compiled with use_xft) on Arch Linux Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". xmonad --recompile doesn't output anything. Attachments: xmonad.hs 4.1 KB -- 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

darcs patch: ThreeColMid - Swap slave window positions
by Anders Engstrom 04 May '09

04 May '09

Sun May 3 21:50:26 CEST 2009 Anders Engstrom <ankaan(a)gmail.com> * ThreeColMid - Swap slave window positions This patch will swap the positions of the two slave windows and this will result in a more intuitive window order. When using focusDown beginning in the master pane we will move in the following graphical order 2->3->1->2->3 instead of 2->1->3->2->1. This is backwards from what is expected. The small drawback is that increasing from 2 to 3 windows (and therefore also columns) will behave in a less intuitive way. The window in the right column will jump to the left of the screen. I think that it is a good idea to make this change since I rely a lot on the window order but people using WindowNavigation may be of a different opinion. An alternative is to add an option to select in what way to behave, but that could be overkill... I leave it up to discussion and devs to decide.

3 3