July 2014 - xmonad - Haskell.org

xmonad hides xfce4-panel
by Damian Philipp 07 Aug '14

07 Aug '14

Hello xmonad experts, I am trying to set up xmonad (0.11 from Ubuntu repository) as a WM for xfce on a fresh install of Lubuntu 14.04. I configured xmonad.hs as instructed on the Wiki page (The file is so short, I included it inline at the end of this mail). When I start xfce using xfwm4 and then run "xmonad --replace" from a terminal, I practically arrive at my dream desktop. However, when I configure xfce to autostart xmonad, I can briefly see the xfce4 panel flash up and then immediately disappear. xmonad just leaves an empty space where the panel is supposed to be. mod-b toggles the empty space but does not show the panel. The default configuraiton of Lubuntu is to have a single panel at the top of the screen. I can revive the panel by briefly running xfwm4: $ killall xmonad-x86_64-linux $ xfwm4 $ xmonad --replace But that is not really a permanent solution. I looked through the archives, but all I cloud find was posts relating to the interaction of the panel workspace indicator and xmonad workspaces, nothing about the panel going AWOL. What do I have to do to make both the panel show up and run xmonad as my default WM to xfce? Regards, Damian Philipp My xmonad.hs: > import XMonad > import XMonad.Config.Xfce > > main = xmonad xfceConfig > { modMask = mod4Mask > , terminal = "xfce4-terminal" }

4 4

Issue 348 in xmonad: Encoding task force
by codesite-noreply＠google.com 05 Aug '14

05 Aug '14

Status: New Owner: ---- Labels: Type-Enhancement New issue 348 by SpencerJanssen: Encoding task force http://code.google.com/p/xmonad/issues/detail?id=348 xmonad is sloppy about strings and encoding. We should go through all of xmonad and make sure all code follows these guidelines: * All String ([Char]) values should be lists of Unicode code points, and should NOT be in UTF-8 or any other encoded form. * All input that creates String values should decoded from bytes in whatever encoding to a lists of code points (this means System.IO and proper locale settings in GHC 6.12, System.IO.UTF8 in older) * All output that takes String values should encode the code points to bytes in whatever encoding (again System.IO in 6.12, utf8-string otherwise) * All non-string data (lists of bytes, encoded strings, etc.) should be stored at types other than [Char] If anybody wants to spearhead this, feel free to come forward. Alternatively we could have maintainers self-certify their modules? -- 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 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