- xmonad - Haskell.org

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

[PATCH] * Allow to limit maximum row count in X.Prompt completion window
by Paul Fertser 21 Feb '13

21 Feb '13

Hi, -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercerpav@gmail.com

4 5

Issue 326 in xmonad: floating windows can break Actions.UpdatePointer
by codesite-noreply＠google.com 20 Feb '13

20 Feb '13

Status: New Owner: ---- New issue 326 by OrbisVicis: floating windows can break Actions.UpdatePointer http://code.google.com/p/xmonad/issues/detail?id=326 What steps will reproduce the problem? 1. UpdatePointer (TowardsCentre 1 1) 2. spiralWithDir West CW (4/5) 3. scratchpadManageHook (W.RationalRect 0.25 0.3 0.5 0.55) 4. Open two windows in the spiral layout, launch the scratchpad, and start tabbing 5. One of the windows will never receive focus -- 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 3

DynamicWorkspaceOrder of a tag
by Jonas 19 Feb '13

19 Feb '13

Hello everyone, (I am an "awesome" convert new to xmonad and I hope this is the right place to ask this question and I am not unknowingly violating some etiquette. If so, please forgive and tell me.) I am using DynamicWorkspaceOrder and want to know the number of a workspace in this order. Basically I am looking for the number that "withNthWorkspace" would use. So given a tag, how can I get its place in the DynamicWorkspaceOrder? Alternatively how can I get a list of all the workspaces in their DynamicWorkspaceOrder? Basically I need to replace the following with something that respects DynamicWorkspaceOrder: myWorkspaces :: [WorkspaceId] myWorkspaces = ["1:main", "2:www", "3:sys"] What I am trying to achieve is to display the number of a workspace next to its name in my dmenu bar, so I know which key binding to use to get there. This would obviously be especially useful for dynamic workspaces. The key bindings are generated via (the DynamicWorkspaceOrder version of) "withNthWorkspace". An alternative might be to modify DynamicLogWithPP but I'd rather not go there if I can avoid it (and I would not know how to do it either). Thanks a lot for your help, Jonas

2 1

Issue 481 in xmonad: UrgencyHook doesn't work for Qt applications
by codesite-noreply＠google.com 19 Feb '13

19 Feb '13

Status: New Owner: ---- New issue 481 by Mike.Lim...(a)gmail.com: UrgencyHook doesn't work for Qt applications http://code.google.com/p/xmonad/issues/detail?id=481 What steps will reproduce the problem? 1. Use Qt application which uses QApplication::alert to mark application as "urgent", for example Skype or qutIM What is the expected output? What do you see instead? UrgencyHook should be executed, but actually nothing happened. What version of the product are you using? On what operating system? xmonad && xmonad-contrib 0.9.2. The darcs version is also affected. OS - Gentoo Linux. As I understand the root cause of the problem is that _NET_WM_STATE_DEMANDS_ATTENTION flag is not handled properly, but Qt uses it internally.

1 2

Issue 532 in xmonad: _NET_WM_STATE_DEMANDS_ATTENTION support
by codesite-noreply＠google.com 19 Feb '13

19 Feb '13

Status: New Owner: ---- New issue 532 by maar...(a)de-vri.es: _NET_WM_STATE_DEMANDS_ATTENTION support http://code.google.com/p/xmonad/issues/detail?id=532 The _NET_WM_STATE_DEMANDS_ATTENTION atom is part of the EWMH specification and can be used to indicate that something happened in a window. It's apparently a somewhat weaker hint than the urgency flag of WM_HINTS, because EWMH say that windows expecting immediate attention should still use WM_HINTS. Either way, the current UrgencyHook doesn't respect _NET_WM_STATE_DEMANDS_ATTENTION. This impacts amongst others all Qt applications, since Qt only uses ..._DEMANDS_ATTENTION and never WM_HINTS. I patched UrgencyHook to also respect _NET_WM_STATE_DEMANDS_ATTENTION. I'm not much of a Haskell expert though, so I suggest someone takes a good look at it and point out what I did wrong. Attachments: ewmh_demands_attention.dpatch 7.9 KB

1 2

Testing GHC HEAD
by Carsten Mattner 17 Feb '13

17 Feb '13

xmonad built fine with GHC HEAD but XMonadContrib failed with the following build error: XMonad/Layout/MultiToggle.hs:162:9: Could not deduce (HList b w0) arising from the ambiguity check for `??' from the context (HList b w) bound by the type signature for ?? :: HList b w => a -> b -> HCons a b at XMonad/Layout/MultiToggle.hs:162:9-42 The type variable `w0' is ambiguous In the ambiguity check for: forall a b w. HList b w => a -> b -> HCons a b In the type signature for `??': ?? :: HList b w => a -> b -> HCons a b Can anyone suggest a fix?

2 1