- xmonad - Haskell.org

Re: Issue 273 in xmonad: Binding multiple keys to the same keysym fails for xmonad hotkeys
by codesite-noreply＠google.com 02 Mar '13

02 Mar '13

Updates: Labels: Type-Enhancement Component-Core Usability Comment #2 on issue 273 by byorgey: Binding multiple keys to the same keysym fails for xmonad hotkeys http://code.google.com/p/xmonad/issues/detail?id=273 (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 5

Re: Issue 158 in xmonad: _NET_WORKAREA support
by codesite-noreply＠google.com 01 Mar '13

01 Mar '13

Updates: Status: Accepted Labels: -Type-Defect Type-Enhancement Comment #6 on issue 158 by byorgey: _NET_WORKAREA support http://code.google.com/p/xmonad/issues/detail?id=158 (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 11

Issue 402 in xmonad: Xmonad becomes unresponsive. No focus changing (using keys or mouse), workspace changing or recompile.
by codesite-noreply＠google.com 01 Mar '13

01 Mar '13

Status: New Owner: ---- New issue 402 by 6181989: Xmonad becomes unresponsive. No focus changing (using keys or mouse), workspace changing or recompile. http://code.google.com/p/xmonad/issues/detail?id=402 What steps will reproduce the problem? 1. No idea. Each time time it's with relatively few windows open (chromium with ~10 tabs and ~4 instances of urxvt). Nothing too heavy. Seems to be random at this point. What is the expected output? What do you see instead? I expect it to...well, no lock up. But it freezes up and none of the keybindings in haskell.hs work (can't even recompile). I can't change workspaces or window focus, but the currently focused window still has its (non-monad related) bindings and functionality work fine (chromium, screen w/ urxvt) and I can still ctrl+alt+F1 to console. Mouse still works, but it doesn't change focus on the windows. What version of the product are you using? On what operating system? Arch x86_64 with kernel 2.6.34-ARCH and xmonad 0.9.1 Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". No --recompile output. See attached for xmonad.hs. Please provide any additional information below. It's done it twice in the less than 24 hours I've had it installed. ivanm @ #xmonad has confirmed this problem also. (see logs for 30/07/10 19:31) Attachments: xmonad.hs 4.8 KB

1 17

Issue 536 in xmonad: wrong monitor's master-slave border moves when I drag
by codesite-noreply＠google.com 28 Feb '13

28 Feb '13

Status: New Owner: ---- New issue 536 by rakslice(a)gmail.com: wrong monitor's master-slave border moves when I drag http://code.google.com/p/xmonad/issues/detail?id=536 What steps will reproduce the problem? 1. run bluetile 2. click in a window on one monitor to focus it 3. move the cursor to the other monitor and drag the master-slave border there What is the expected output? What do you see instead? I'd expect the master-slave border i'm dragging to move; instead the master-slave border on the other monitor moves. What version of the product are you using? On what operating system? 0.6 (ubuntu 12.06 amd64's bluetile 0.6-1 package) Additional: I've arranged my monitors in a sideways T shaped desktop layout in the gnome display control panel. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 0

[PATCH] * Export X.L.Gaps Gaps constructor
by Paul Fertser 27 Feb '13

27 Feb '13

Hi, Since it's adviced everywhere to attach patches (in the absence of a functional MTA setup), here it goes, attached. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercerpav@gmail.com

3 6

Issue 535 in xmonad: Xmonad-contrib-0.11 Fails to compile against latest version of X11 lib
by codesite-noreply＠google.com 27 Feb '13

27 Feb '13

Status: New Owner: ---- New issue 535 by rbtitot...(a)gmail.com: Xmonad-contrib-0.11 Fails to compile against latest version of X11 lib http://code.google.com/p/xmonad/issues/detail?id=535 What steps will reproduce the problem? 1. cabal install xmonad-contrib What is the expected output? What do you see instead? Not Compiling: [ 39 of 226] Compiling XMonad.Hooks.DebugEvents ( XMonad/Hooks/DebugEvents.hs, dist/build/XMonad/Hooks/DebugEvents.o ) XMonad/Hooks/DebugEvents.hs:215:61: Ambiguous occurrence `getAtomName' It could refer to either `XMonad.Hooks.DebugEvents.getAtomName', defined at XMonad/Hooks/DebugEvents.hs:57:1 or `XMonad.getAtomName', imported from `XMonad' at XMonad/Hooks/DebugEvents.hs:(24,1)-(26,62) (and originally defined in `Graphics.X11.Xlib.Atom') What version of the product are you using? On what operating system? Ubuntu 12.04 lts Xmonad-contrib-0.11, xmonad-0.11, libx11-dev v 2:1.4.9901-0ubuntu2 Please provide any additional information below. Looks like this was fixed in xmonad, but not in xmonad-contrib -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 1

Frequent xmonad crashes (SIGBUS)
by Zev Weiss 26 Feb '13

26 Feb '13

Hi, I'm running xmonad-0.11 and getting outright crashes fairly frequently, often multiple times per week with my usage patterns. I can't pin it directly to any particularly specific action (like opening/closing a certain window), but it tends to happen upon returning to my machine after being away for a while with the screen locked (with gnome-screensaver, for what it's worth) -- commonly, I return to my workstation after being away from it overnight (or a weekend), and upon entering my password and returning to my desktop, xmonad catches SIGBUS and promptly dies. It has occasionally occurred under other circumstances, just during normal use (e.g., switching windows & workspaces), though the screen-unlocking situation is by far the most crash-prone. I installed it with cabal & ghc from haskell-platform 2012.2.0.0: [me@host: tmp]% cabal --version cabal-install version 0.14.0 using version 1.14.0 of the Cabal library [me@host: tmp]% ghc --version The Glorious Glasgow Haskell Compilation System, version 7.4.2 Libraries: utf8-string 0.3.7 X11 1.6.0.2 X11-xft 0.3.1 xmonad-contrib-0.11 Other potentially-relevant info: RHEL 6.3, x86_64 X.org 1.10.6, dual-head I have a core file saved via gdb from when it catches the SIGBUS -- I don't think it has anything terribly revealing in it, but I'm slightly hesitant to post it publicly, so if it would be useful for debugging, let me know and I can send it directly (23MB bzipped, 5.8MB xz'd). Please let me know if there's any other information I could provide that would be helpful. Thanks, Zev Weiss

4 5

Re: [xmonad] [evince] Page Scrolling breaks after Workspace Switch
by Ben Boeckel 25 Feb '13

25 Feb '13

On Sat, 16 Feb, 2013 at 19:00:14 GMT, Reto Hablützel wrote: > Does someone else have the same behavior? > Any help is appreciated. Also, I'd be happy for hints as to where to search > for the problem as I do not know gtk at all. Maybe evince isn't getting the KeyUp events for modfiers? I see a similar thing with uzbl. Apps should probably probably act as if KeyUp occurred on all modifiers on a loss of keyboard focus. --Ben

2 1

Re: [xmonad] restackWindow / raiseWindow
by Jochen Keil 24 Feb '13

24 Feb '13

Hello, sorry for taking so long, life got in my way.. Nevertheless, here's a patch as a possible solution to the discussed problem. A minor problem is that floating windows still have their stacking order forced. However, I don't think that this behaviour can be changed easily. Yet, the stacking order for tiled windows is now configurable freely on a per-layout basis. This gives interesting new possibilities, especially for small screens, like tiling expanded to the third dimension. Best Wishes, Jochen 1 patch for repository http://code.haskell.org/xmonad: Sun Feb 24 10:43:28 CET 2013 jochen.keil(a)gmail.com * Move window stacking (z-axis) to the layout This implements a default policy for the stacking order of windows, much like the previous implementation. However, the old implementation forced the stacking order on every layout. Now this can be controlled separately by every layout itself. Floating will be still put on top of all other windows.

1 0

Re: [xmonad] [PATCH] * Allow to limit maximum row count in X.Prompt completion window
by Gwern Branwen 21 Feb '13

21 Feb '13

On Thu, Feb 21, 2013 at 2:48 PM, adam vogt <vogt.adam(a)gmail.com> wrote: > So the constructor that's almost certainly not used is XPC. In any > case, probably nobody has gone to the trouble of specifying the 20-odd > fields outside of the definition of defaultXPConfig. Whups. In that case, XPC is used by one config: http://www.haskell.org/haskellwiki/index.php?title=Xmonad/Config_archive/Ro… (bottom of page). Sorry Rob. Guess you'll have to take one for the team. -- gwern http://www.gwern.net

1 0