- xmonad - Haskell.org

Issue 399 in xmonad: Bringing focus to a floating window when in monocle layout can cause the main window to switch
by codesite-noreply＠google.com 30 Jun '10

30 Jun '10

Status: New Owner: ---- New issue 399 by adam.vany: Bringing focus to a floating window when in monocle layout can cause the main window to switch http://code.google.com/p/xmonad/issues/detail?id=399 What steps will reproduce the problem? 1. Open 1 window (we will call F) and Mod+Mouse1 to make floating 2. Open 1 more windows (called A) 3. Keep focus on window A and open another window (called B) 4. Mod+Space until in monocle layout. Window B should be visible with window F floating on top 5. Move the mouse onto window F to give it focus What is the expected output? What do you see instead? Expected: Giving focus to a floating window doesn't change the order/layout of non-floating windows. Window B should remain visible when window F receive focus Actual: Window B is replace with Window A. If you use Mod+j or Mod+k to bring window B back again, as soon as you move the mouse on to window F, Window B is replace with window A again What version of the product are you using? On what operating system? xmonad 0.7 on debian lenny Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". xmonad.hs: import XMonad import XMonad.Hooks.DynamicLog import XMonad.Hooks.ManageDocks main = xmonad $ defaultConfig { terminal = "urxvt" , layoutHook = avoidStruts $ layoutHook defaultConfig }

1 1

Issue 388 in xmonad: Google Chrome's dialog changes size back and forth rapidly
by codesite-noreply＠google.com 30 Jun '10

30 Jun '10

Status: New Owner: ---- New issue 388 by wei.hoo: Google Chrome's dialog changes size back and forth rapidly http://code.google.com/p/xmonad/issues/detail?id=388 What steps will reproduce the problem? 1. Start Google Chrome/Chromium. 2. Go to Options -> Under the Hood -> Clear browsing data... 3. Or Options -> Personal Stuff -> Import data from another browser... What is the expected output? What do you see instead? A dialog pops up (assuming you've set up xmonad to float dialogs), but it's shaking all the time and basically useless. Tiling the dialog does make it usable, but it's just a workaround. What version of the product are you using? On what operating system? Darcs version on Arch. Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". Please provide any additional information below. I'm not really sure whether to blame XMonad or Google Chrome. Attachments: xmonad.hs 9.5 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 9

darcs patch: add XMonad.Hooks.PlaceNext
by Ben Boeckel 28 Jun '10

28 Jun '10

Hi, I found FloatNext recently and thought it'd be useful to do something similar with where the next window gets placed. I also found InsertPosition which did what I wanted, but not conditionally. The new hook is a wrapper around InsertPosition that utilises FloatNext's conditional ability. Feedback welcome. --Ben

2 2

xmonad for native OS X apps
by James O'Beirne 27 Jun '10

27 Jun '10

Hey all, First I'd like to thank the developers for xmonad; it's a fantastic piece of work. This is so much the case that I'm finding myself frustrated with my new MacBook Pro's default operating system. I want real tiling, not some click-and-drag grid app that costs $13. Xmonad, as things stand, only works under X11 for OS X. I'm curious as to what would be involved in extending (or perhaps forking) xmonad to deal with native OS X applications. Obviously, this would be arduous but i. Is it feasible? ii. If so, is there any interest in such development? I don't know anything about Applescript, Quartz, or Cocoa, but I'd certainly be willing to learn should it be shown that a project like this is reasonable. Thanks, James

2 1

Skype in the IM layout - again
by Nathan Huesken 26 Jun '10

26 Jun '10

Hi, I asked the question a while ago, it never worked for me but I stopped worring because I started using pidgin instead of skype ... The question is how to get the IM layout to accept the skype buddy list. I finally tried this: withIM (1%7) skype (LG.Grid False) where skype = Title "<username> - Skype™ (Beta)" where I actually copied the string "<username> - Skype™ (Beta)" from the xprop output. But it does not work :(. What could this be? Maybe the "TM" symbol is recognized incorrectly? Can I somehow change this, so it is recognized when the title only contains my <username>? Thanks! Nathan

2 1

Re: darcs patch: add XMonad.Hooks.PlaceNext
by Ben Boeckel 26 Jun '10

26 Jun '10

Ben Boeckel <mathstuf-Re5JQEeQqe8AvxtiuMwx3w(a)public.gmane.org> wrote: <snip> Hi, Sorry for the self-reply, but I reworked the code to be more general and support toggling of any ManageHook. I also have a patch for X.H.FocusNext if it isn't going to be deprecated (unsure of whether a module which just curry's another module's functions and re-export is worth hanging around). X.H.InsertPosition could also be rewritten or deprecated as well. It is probably worth keeping around because of the ``workaround'' I had to do to get dependent ManageHooks to interact properly. Probably worth documenting as well. myManageHook = composeAll [ goBelow =? False --> (toggleHook hFocus $ doF W.focusDown) , goBelow --> (toggleHook hFocus $ doF W.focusUp) , toggleHook hBelow $ doF W.swapDown ] where goBelow = liftX $ willHook hBelow Since the above/below hook swaps how the focus should be changed, it needs to be meta-conditioned as to which direction to swap the focus. Maybe an operator should be added to go along with (-->) to do if/then/else rather than just if/then. An operator similar to <!> might also be nice. I can write these patches up if so. --Ben

1 1

Full-screen for Google Chrome
by Weeble 26 Jun '10

26 Jun '10

Currently, Google Chrome won't go full-screen for me in xmonad, although it will in metacity. Pressing F11 has no effect. Based on this http://code.google.com/p/chromium/issues/detail?id=42467 I think that this http://code.google.com/p/xmonad/issues/detail?id=339 is the relevant issue. Is the code in there what I need? If I figure out the appropriate bits to copy into my xmonad.hs file will it let me full-screen Chrome? Are there any other issues with it?

1 0

Issue 397 in xmonad: Mouse pointer on border locks focus when using unclutter
by codesite-noreply＠google.com 22 Jun '10

22 Jun '10

Status: New Owner: ---- New issue 397 by sachdochma: Mouse pointer on border locks focus when using unclutter http://code.google.com/p/xmonad/issues/detail?id=397 What steps will reproduce the problem? 1. Set focusFollowsMouse = True in your ~/.xmonad/xmonad.hs. 2. Run: unclutter -root -idle 1 (this hides the mouse pointer after 1 second of idleness) 3. Open at least two windows on the current workspace. 4. Put your mouse pointer on the border of the focused window. 5. Try to change focus to another window. What is the expected output? What do you see instead? The focus changes for an estimated millisecond as expected, then it switches back immediately. What version of the product are you using? On what operating system? xmonad 0.9.1-2+b1 from the Debian repo. Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". Yes, I am, but there is no output. Please provide any additional information below. This only happens when the mouse pointer is invisible, so i suppose unclutter is doing something stupid and this is not xmonad’s fault? Is it possible to move the mouse pointer to the corner of the screen after a certain period of mouse idleness?

1 4

X consuming a lot of CPU
by Ivan Lazar Miljenovic 22 Jun '10

22 Jun '10

Every now and then I find that Xorg suddenly uses a lot of CPU for a while, making xmonad non-responsive. In general, this seems to be a fault of either Firefox or Emacs (in that xrestop says Firefox is using the most responses but for me it usually becomes unresponsive whilst I'm using Emacs). As of today, xorg has been using at least 60% of my CPU most of the time, making xmonad very non-responsive. I was thinking that the issue was with xmonad, especially when I subsequently booted into KDE and had no problems. However, that seems to not be the case: the problem was my terminal emulator (I realised this when I noticed that the most CPU usage was occurrring whilst looking at the top output in my terminal). I'm normally use Xfce's Terminal [1], and it seems that it seems to be the cause of the problems: when I switched to xterm, my problems all disappeared (and when I was in KDE, I was using Konsole, not Terminal). [1]: http://www.xfce.org/projects/terminal I would be interested in hearing if anyone else has similar problems and uses another vte-based terminal emulator (such as Gnome's terminal); more specifically, if using a different terminal emulator solves their problem. For comparison purposes, I have vte-0.24.1 and Terminal-0.4.5. -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com

3 5

darcs patch: XMonad.Core: escape slashes, ln module
by gwern0＠gmail.com 21 Jun '10

21 Jun '10

1 patch for repository community.haskell.org:/srv/code/xmonad: Sun Jun 20 13:57:41 EDT 2010 gwern0(a)gmail.com * XMonad.Core: escape slashes, ln module

3 2