June 2011 - xmonad - Haskell.org

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 21 Jan '12

21 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 29 Dec '11

29 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

Issue 410 in xmonad: Real fullscreen support without floating
by codesite-noreply＠google.com 24 Dec '11

24 Dec '11

Status: New Owner: ---- New issue 410 by demelier.david: Real fullscreen support without floating http://code.google.com/p/xmonad/issues/detail?id=410 The mplayer fullscreen bug is a quite famous right now. Some people use NoBorders as workaround, but the window is still moveable. I mean real fullscreen as the window can't be moved by the user and of course won't have any borders without any workaround. This applies for mplayer's fullscreen mode, not for SDL.

1 3

Issue 363 in xmonad: non-positive argument error on NVidia Xinerama set
by codesite-noreply＠google.com 13 Dec '11

13 Dec '11

Status: New Owner: ---- New issue 363 by seanerussell: non-positive argument error on NVidia Xinerama set http://code.google.com/p/xmonad/issues/detail?id=363 What steps will reproduce the problem? 1. 2. 3. What is the expected output? What do you see instead? What version of the product are you using? On what operating system? Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". Please provide any additional information below. -- 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 10

Issue 412 in xmonad: Using a compositing manager shifts windows 2px to top and left
by codesite-noreply＠google.com 27 Nov '11

27 Nov '11

Status: New Owner: ---- New issue 412 by DaPatti: Using a compositing manager shifts windows 2px to top and left http://code.google.com/p/xmonad/issues/detail?id=412 What steps will reproduce the problem? 1. Start XMonad 2. Start cairo-compmgr or xcompmgr What is the expected output? What do you see instead? Instead of their normal positioning, windows are shifted to the top left a bit so that the borders on the top and left aren’t visible anymore. As soon as I kill the compositing manager, the windows are repositioned correctly. What version of the product are you using? On what operating system? XMonad 0.9.1; Arch Linux x86_64. Tried with cairo-compmgr-git and xcompmgr. Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". The only relevant part might be borderWidth = 2. I don’t use FadeInactive or things like that. No messages on xmonad --recompile. Please provide any additional information below.

1 2

Issue 455 in xmonad: xmonad munges dialogs
by codesite-noreply＠google.com 25 Nov '11

25 Nov '11

Status: New Owner: ---- New issue 455 by hramr...(a)gmail.com: xmonad munges dialogs http://code.google.com/p/xmonad/issues/detail?id=455 When you move a workspace containing a floating dialog from one screen to another the dialog changes size. For some reason when the dialog appears on different screen than the app was last show it is (at least sometimes) munged as well. Note that the dialog has an application specified size at the start so I don't see any reason to resize it later.

1 3

Issue 396 in xmonad: Qt (and KDE) don't display menu if not on first display
by codesite-noreply＠google.com 24 Nov '11

24 Nov '11

Status: New Owner: ---- New issue 396 by luka.stojanovic: Qt (and KDE) don't display menu if not on first display http://code.google.com/p/xmonad/issues/detail?id=396 What steps will reproduce the problem? 1. Open Qt or KDE app 2. Place it on second display 3. try opening menu or context-menu What version of the product are you using? On what operating system? Ubuntu 10.04, amd64, xmonad 0.9 Please provide any additional information below. Qt apps that I've tried: VLC, Psi KDE apps that I've tried: Krusader, Amarok, Dolphin...

1 8

darcs patch: Export types to reduce haddock warnings.
by Adam Vogt 18 Nov '11

18 Nov '11

1 patch for repository code.haskell.org:/srv/code/XMonadContrib: Sat Oct 23 15:57:55 EDT 2010 Adam Vogt <vogt.adam(a)gmail.com> * Export types to reduce haddock warnings.

2 1