- xmonad - Haskell.org

darcs patch: config-mate
by allbery.b＠gmail.com 02 Aug '14

02 Aug '14

** tested version ** 1 patch for repository http://code.haskell.org/XMonadContrib: Sat Aug 2 22:06:59 EDT 2014 allbery.b(a)gmail.com * config-mate Initial support for the Mate desktop environment (http://mate-desktop.org) Based on existing Gnome 2 support, since Mate is a maintained fork of Gnome 2.

1 0

darcs patch: debug-managehook
by allbery.b＠gmail.com 02 Aug '14

02 Aug '14

** tested version ** 1 patch for repository http://code.haskell.org/XMonadContrib: Sat Aug 2 22:06:01 EDT 2014 allbery.b(a)gmail.com * debug-managehook A set of hooks, and convenience combinators, to help with ManageHook debugging. Ordinary users may well want to use debugManageHookOn in normal configs, specifying a key sequence which can be pressed before running a command in order to capture debug information just for that command's main window. This is especially useful when trying to diagnose issues such as programs that do not play well with SpawnOn, or ManageHook matching on 'title' when the program does not set the window title until after it is mapped.

1 0

darcs patch: debug-debug
by allbery.b＠gmail.com 02 Aug '14

02 Aug '14

** tested version ** 1 patch for repository http://code.haskell.org/XMonadContrib: Sat Aug 2 22:05:30 EDT 2014 allbery.b(a)gmail.com * debug-debug Various fixes and enhancements to DebugWindow and DebugStack. ManageDebug requires these fixes, but some of them are significant even if not using ManageDebug.

1 0

darcs patch: debug-managehook
by allbery.b＠gmail.com 02 Aug '14

02 Aug '14

1 patch for repository http://code.haskell.org/XMonadContrib: Sat Aug 2 21:51:24 EDT 2014 allbery.b(a)gmail.com * debug-managehook A set of hooks, and convenience combinators, to help with ManageHook debugging. Ordinary users may well want to use debugManageHookOn in normal configs, specifying a key sequence which can be pressed before running a command in order to capture debug information just for that command's main window. This is especially useful when trying to diagnose issues such as programs that do not play well with SpawnOn, or ManageHook matching on 'title' when the program does not set the window title until after it is mapped.

2 1

darcs patch: debug-debug
by allbery.b＠gmail.com 02 Aug '14

02 Aug '14

1 patch for repository http://code.haskell.org/XMonadContrib: Sat Aug 2 21:49:01 EDT 2014 allbery.b(a)gmail.com * debug-debug Various fixes and enhancements to DebugWindow and DebugStack. ManageDebug requires these fixes, but some of them are significant even if not using ManageDebug.

1 0

Issue 531 in xmonad: Multiple workspaces with the same name confuses XMonad
by codesite-noreply＠google.com 14 Jul '14

14 Jul '14

Status: New Owner: ---- New issue 531 by erdnussb...(a)gmail.com: Multiple workspaces with the same name confuses XMonad http://code.google.com/p/xmonad/issues/detail?id=531 What is the expected output? What do you see instead? I expect that xmonad differs between workspaces even if they have the same name. The following describes the scenarios you run into when naming multiple workspaces identically. ------------------- Scenario 1: ------------------- How to produce: 1. Give some workspaces the same name. 2. Restart and recompile XMonad. What happens: The renamed workspaces are added uselessly to the beginng of the list. (see picture 1.png) ------------------- Scenario 2: ------------------- How to produce: 1. Start from scenario 1. 2. Restart X. What happens: XMonad shows all the workspaces separately but addresses them as one (see picture 2.png). Additional information: If you switch between two workspaces with the same name, xmonad loads the content again (you see it flicker) but the content is the same. ------------------- Scenario 3a: ------------------- How to produce: 1. Start from scenario 2. 2. Change one of the former identical workspace names to something unique. 3. Recompile and restart XMonad. What happens: XMonad displays mutliple times the unique name?! (see picture 3a.png) Additional information: From this point on, recompiling and restarting doesn't fix the corruption of the running XMonad session. ------------------- Scenario 3b: ------------------- How to produce: 1. Start from Scenario 3a 2. Restart X What happens: The multiple workspaces are shown again, still addresses as one, but the uniquely named workspace is displayed and addressed correctly. (see picture 3b.png) ------------------- Scenario 3c: ------------------- How to produce: 1. Start from Scenario 3b. 2. Change all workspace names to something unique again. 3. Recompile and Restart Xmonad. What happens: The doesn't have the intended effect, instead some workspace keys stop working and a random one is shown mutliple times. (see picture 3c.png) Restarting X fixes this issue. 4. Start with Scenario 1 again, it's fun (: ------------------- What version of the product are you using? On what operating system? Linux ******* 3.2.0-4-amd64 #1 SMP Debian 3.2.35-2 x86_64 GNU/Linux (wheezy) xmonad 0.10 ------------------- Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". Yes I'm using it, there are no compilation errors. ------------------- Please provide any additional information below. Dzen2 and Xmobar showed the same effects. Attachments: 1.png 116 KB 2.png 122 KB 3a.png 137 KB 3b.png 115 KB 3c.png 116 KB xmonad.hs 10.8 KB

1 4

Re: [xmonad] [Haskell-cafe] How to have a managed window unfocusable?
by Brandon Allbery 06 Jul '14

06 Jul '14

On Sun, Jul 6, 2014 at 10:57 PM, Magicloud Magiclouds < magicloud.magiclouds(a)gmail.com> wrote: > Thank you for the explanation. I always thought "focus" was managed by WM. > Explicit focus is managed by the WM. But you don't explicitly choose a window to receive focus when the focused window goes away. The window manager is not invoked then, instead the server checks the focus inheritance policy *of the window that just closed*. And the default is to give focus to (the X server's idea of) the "previous window". It doesn't ask the window manager which that is, or ask the window manager to change the focused window; it determines that and assigns focus itself, and the window manager finds out about it from the subsequent FocusIn event. > Is "above" also controlled by X instead of WM? I tried to patch the code > of the clock to manage itself (keep itself topmost), but did not seem to > work. > Older programs do it themselves; modern programs tend to expect the window manager to do it based on EWMH hints, but xmonad does not implement the window layers part of the spec --- and it's not clear *how* to implement it in xmonad's model, as it runs into the same problems as Bug 4 (all the horrible problems with floating windows in xmonad's model). More or less, the way you'd have to do it is to call XRaiseWindow() regularly, possibly in response to any X11 event other than Expose (sending it on that event risks an infinite loop since the server will generate an Expose event if any part of your window was covered). (This kind of thing is why EWMH moved it into the window manager. Now if only we could do it right given how the StackSet works....) -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

1 0

Re: [xmonad] [Haskell-cafe] How to have a managed window unfocusable?
by Brandon Allbery 06 Jul '14

06 Jul '14

On Sun, Jul 6, 2014 at 10:23 PM, Magicloud Magiclouds < magicloud.magiclouds(a)gmail.com> wrote: > I'd like to have a transparent clock floating on my desktop. > > If I made it ignored (unmanaged), it would not be above and would be > blocked by other windows. > > If I made it managed and float, when I floated up and down, it would be > focused and I needed to press hotkey again to move focus to correct window. > > Anyway I could manage it, but not focusing on it? > This is difficult, because X11 expects that the way you do this is to unmanage it *and* that a window that is unmanaged knows how to manage itself. In particular, the X server may well send focus to a managed window *itself* via its window focus inheritance policy. The best xmonad could do would be to use a handleEventHook to detect the window being given focus (this might be rather difficult because focusIn and focusOut events are not currently delivered by the Haskell X11 bindings, sigh) and send focus elsewhere --- but in that case the window would still briefly receive focus. You probably need to find a clock program that knows how to operate as an unmanaged window. -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

1 0

Chromium floating required
by Carsten Mattner 02 Jul '14

02 Jul '14

I tried current Chromium and Chrome to test some websites and found out that the new version requires for Chromium to be floating or else there's glitches and corrupted drawing. Anyone else seen this?

3 3

[xmonad-contrib] XMonad.Actions.Search - add DuckDuckGo Search engine?
by ardumont 17 Jun '14

17 Jun '14

Hello, Can it be possible to integrate this patch? This adds DuckDuckGo - https://duckduckgo.com/?t=lm search engine to the default list. Cheers, -- @ardumont

3 2