November 2011 - xmonad

Issue 420 in xmonad: countScreens from the contrib module X.L.IndependScreens has side effects
by codesite-noreply＠google.com 29 Feb '12

29 Feb '12

Status: New Owner: ---- New issue 420 by quesel: countScreens from the contrib module X.L.IndependScreens has side effects http://code.google.com/p/xmonad/issues/detail?id=420 The function countScreens does not close the display after counting the number of screens. This is unfortunate as counting the number of screens should be side effect free. The patch below changes this function in a way that after performing its operation the display is closed correctly. Regards, Jan Attachments: countScreensCloseDisplay.patch 51.0 KB

1 2

Issue 456 in xmonad: xmonad partially eats key events comprising a WM shortcut
by codesite-noreply＠google.com 28 Feb '12

28 Feb '12

Status: New Owner: ---- New issue 456 by hramr...(a)gmail.com: xmonad partially eats key events comprising a WM shortcut http://code.google.com/p/xmonad/issues/detail?id=456 When I invoke a keyboard shortcut of XMonad this happens: Mod key down (eg. Super) is received by application action key down (eg. C) is eaten by XMonad <At this point Mod release should be sent to application> , action is performed. action key release and Mod key release is eaten by XMonad Mod is stuck down in application XMonad should send key release for modifiers it ate to the application. It should do so before performing the action bound to the key because at that point it is known the key will be eaten and the application that received the bogus key down is still active. If the action is some WM action that switches windows the only time when this fixup can reasonably happen is before performing the action.

1 10

Re: Issue 276 in xmonad: switching keyboard focus to a wine app is odd
by codesite-noreply＠google.com 28 Feb '12

28 Feb '12

Comment #2 on issue 276 by byorgey: switching keyboard focus to a wine app is odd http://code.google.com/p/xmonad/issues/detail?id=276 What is it about the way xmonad and wine interact that cause this? Obviously keyboard focus works fine for (almost) all other applications, so what's different about wine? -- 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 4

Issue 479 in xmonad: xmonad & xft slow font rendering
by codesite-noreply＠google.com 28 Feb '12

28 Feb '12

Status: New Owner: ---- New issue 479 by wol...(a)gmail.com: xmonad & xft slow font rendering http://code.google.com/p/xmonad/issues/detail?id=479 What steps will reproduce the problem? 1. Start gnome3 environment 2. Open resource manager and vim with arbitrary large file 3. Scroll with your keyboard up and down 4. Notice that cpu-consumption and ui-performance differs considerably with the same steps reproduced in xmonad. What is the expected output? What do you see instead? I expect at least the same performance. What version of the product are you using? On what operating system? Arch linux x86_64. xmonad 0.9.2 Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". Please provide any additional information below. I use xmonad for quite some time. But today I was curious about gnome 3 and what I noticed is that font rendering in gnome 3 was significantly faster than in xmonad. This was strange for me, because I don't even use composite managers with my xmonad setup. I dig it a little and found, that the source of problem may be xft, which is used by default. Also, it's unlikely to be a hardware problem, because my setup is i7/8gb/ati hd5470. Attachments: xmonad.hs 6.0 KB

1 1

Issue 472 in xmonad: [PATCH] XMonad/Prompt/Directory.hs fix issue on standard unixes
by codesite-noreply＠google.com 25 Feb '12

25 Feb '12

Status: New Owner: ---- New issue 472 by graude...(a)gmail.com: [PATCH] XMonad/Prompt/Directory.hs fix issue on standard unixes http://code.google.com/p/xmonad/issues/detail?id=472 XMonad/Prompt/Directory.hs is using /bin/bash, this is not only unportable, but also very not standard. Because of this XMonad/Prompt/Directory.hs doesn't work on FreeBSD for example. Because there is no /bin/sh, you can however install bash to /usr/local/bin/ Attached patch fixes this by simply removing /bin/ and leaving shell to figure out where is bash located I'm using xmonad and xmonad-contib 0.9.2 from FreeBSD ports Attachments: patch-XMonad__Prompt__Directory.hs 490 bytes

1 1

Comparison of "extensible window managers"
by Teika Kazura 15 Feb '12

15 Feb '12

Hi, Xmonad list. I think Xmonad is one of window managers "extensible" by users, or programmable, offering the API and allowing users to override the core code, or freely define new behaviors, though I haven't tried Xmonad actually yet. I'm a former developer of Sawfish which might be the first of such kind of WMs, using a Lisp dialect. I'm interested in comparing them, and created a wiki page for it: http://sawfish.wikia.com/wiki/Comparison_of_extensible_window_managers There Awesome and StumpWM are also studied. If someone is interested, please improve that article. Feel free to add any subjects. Or if you don't feel like editing wiki, you can comment here, and I'll do the actual edit. Of course I'll be glad to answer any questions about Sawfish. # I envy the fact that Xmonad's web site is so well tidy. I tried a lot # in improving Sawfish manual and wiki, but I felt as if I was trying # to move a mountain. With best regards, Teika (Teika kazura)

5 14

Issue 450 in xmonad: ManageDocks should check for multi window types in _NET_WM_WINDOW_TYPE
by codesite-noreply＠google.com 07 Feb '12

07 Feb '12

Status: New Owner: ---- New issue 450 by icarnales: ManageDocks should check for multi window types in _NET_WM_WINDOW_TYPE http://code.google.com/p/xmonad/issues/detail?id=450 According to the spec: _NET_WM_WINDOW_TYPE _NET_WM_WINDOW_TYPE, ATOM[]/32 This SHOULD be set by the Client before mapping to a list of atoms indicating the functional type of the window. This property SHOULD be used by the window manager in determining the decoration, stacking position and other behavior of the window. The Client SHOULD specify window types in order of preference (the first being most preferable) but MUST include at least one of the basic window type atoms from the list below. This is to allow for extension of the list of types whilst providing default behavior for Window Managers that do not recognize the extensions. http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html What steps will reproduce the problem? 1. Launch a program with multiple window types like DOCK and NORMAL (tested with unity-2d panel and launcher) What is the expected output? What do you see instead? The window should be ignored and a gap must be created to accommodate it. Instead the window is treated normally. What version of the product are you using? On what operating system? 0.9 Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". Any config with ManageDocks (tested with desktopConfig and manual ManageDocks) will do. Please provide any additional information below. I think checkDock function should be in a more generic place like Hooks/ManageHelpers that are currently using the isInProperty function to check for property values.

1 1

Problem with anti-aliased fonts in Java/Swing applications
by Christophe Garion 22 Jan '12

22 Jan '12

Hello, I have a problem with xmonad under Debian with no particular config (no Config.Gnome etc.): in every Swing application, fonts are not anti-aliased, which is ugly. If I add the -Dawt.useSystemAAFontSettings=on option when I start a jvm, fonts are anti-aliased. There is no global property file in Oracle jdk to configure this (notice that the problem is the same for openjdk). I can use the _JAVA_OPTIONS environment variable to set this option, but it adds comments in the console every time I launch a java application, which I do not want. There is no problem with GTK applications. If I start a gnome-session from xmonad, fonts in swing applications are correctly anti-aliased. Is there a way to correct this problem? Sorry if an answer has already been provided, but I did not find any searching the web and Xmonad website. Thanks in advance, Christophe -- Christophe Garion ISAE/DMIA - SUPAERO/IN garion(a)isae.fr 10 avenue Edouard Belin Tél : (33)5 61 33 80 57 BP 54032 Fax : (33)5 61 33 83 45 31055 Toulouse Cedex 4

3 4

Re: Issue 339 in xmonad: Support for toggling totem movie player fullscreen
by codesite-noreply＠google.com 02 Jan '12

02 Jan '12

Updates: Summary: Support for toggling totem movie player fullscreen Status: Accepted Labels: -Priority-Low Priority-Medium Comment #5 on issue 339 by wirtwo...(a)gmail.com: Support for toggling totem movie player fullscreen http://code.google.com/p/xmonad/issues/detail?id=339 Nice work audunskaugen. Thanks for researching this and providing the _NET_WM_STATE_FULLSCREEN event hook (totemFullscreen.hs sample xmonad.hs). IMO, this will be good to get into contrib soon to make it available for more usage, testing and further development. There are some aspects to improve so if anyone wants to take on ownership and submit a patch addressing them that would be great. Otherwise if no action in a week or so I'll send a patch to add it to EwmhDesktops as is, initially as a standalone 'fullscreenEventHook'. Eventually, though, I think it would be good to include an improved version in the standard ewmhDesktopsEventHook, plus having it available by itself. (sjanssen feedback on IRC when asked for thoughts as to where to put this: "enabling the full screen event hook in EWMH would be fine, and would probably make sense.") As is it gives more function for totem users and surely some other similar apps too than the current (0.9) situation, but also with some additional work it seems like it can cover uses of the doFullFloat manageHooks with isFullscreen and the fullscreen query alexey attached to http://code.google.com/p/xmonad/issues/detail?id=333 It seems it covers tiled to fullscreen and back usage plus allowing multihead users to focus other screens without affecting fullscreened apps. In my quick tests it works for totem, flash, mplayer, mplayer-plugin, gnome-mplayer plugin. (This is with all fullscreen manageHooks disabled.) It doesn't seem to help with ooimpress unfortunately, nor evince. Areas to address: * Toggling seems less smooth than it should be. In my tests it appears that the window untiles, goes to hinted float size, then finally fullscreen although it's hard to tell as it's very rapid. There is some glitch anyway that I didn't research yet as to cause. Also other tiled windows from the same workspace look briefly as if they are composited with the fullscreen app since they change size to fill the space as the fullscreen app floats. Not sure how much improvement can practically be made here, but hopefully can something close to the nice mapping with fullscreen manageHook. * Whether a window starts out tiled or floating, once toggled fullscreen and back it restores to tiled state. My reading of wm-spec and probably most users expectations is that floats return to float instead. I don't think PositionStore would be needed for this but didn't look into it yet either. audunskaugen, thanks again. If you'd like please send a darcs patch to X.Hooks.EwmhDesktops, or if you want to be credited by some other name you are welcome to email me privately with your preference and I'll include in any patch I prepare. -- 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 12

Issue 440 in xmonad: Lives preference dialog infinite loop
by codesite-noreply＠google.com 30 Dec '11

30 Dec '11

Status: New Owner: ---- New issue 440 by vox.cogi...(a)gmail.com: Lives preference dialog infinite loop http://code.google.com/p/xmonad/issues/detail?id=440 Steps to reproduce: 1. Install and start the Lives video editor. 2. Open preferences window(C-p). The preference window will then cycle very rapidly between two sizes, using near-100% CPU. Tested using xmonad-0.9.2 on Arch linux. Attachments: xmonad.hs 1.3 KB

1 6