- xmonad - Haskell.org

Vertical tabs
by Max Rabkin 10 Mar '10

10 Mar '10

There seems to be no way to get a tabbed layout with vertical tabs. Is this correct? How hard would it be to write a vertical tabbed layout? (I'm willing to try, but my knowledge of Xlib is non-existent). --Max

1 0

[patch] Retracting window drawers
by Max Rabkin 10 Mar '10

10 Mar '10

Hi, I spent a little time trying to optimize my Gimp experience, and in the process developed this layout modifier. Based on a Property, it places some windows in a "draw" which retracts to a narrow strip at the edge of the screen until one of the windows in it gets focus, when it opens over the underlying windows. Hope it's useful. --Max

3 2

darcs patch: X.A.PhysicalScreens cleaning and allow c... (and 3 more)
by Anders Engstrom 08 Mar '10

08 Mar '10

Mon Mar 8 12:37:04 CET 2010 Anders Engstrom <ankaan(a)gmail.com> * X.A.PhysicalScreens cleaning and allow cycling Remove redundant import to supress warning, did some refactoring to use xmonad internal things to find screens instead of using X11-stuff. Also added ability to cycle between screens in physical order. Mon Mar 8 12:43:18 CET 2010 Anders Engstrom <ankaan(a)gmail.com> * X.L.LayoutScreens split current screen This patch will allow the user to split the currently focused screen instead of all screens together. This is usefull for multiscreen users who have functioning xinerama, but wish to split one of the screens. Mon Mar 8 12:50:22 CET 2010 Anders Engstrom <ankaan(a)gmail.com> * X.U.Dmenu helpers to run dmenu with arguments Mon Mar 8 12:54:02 CET 2010 Anders Engstrom <ankaan(a)gmail.com> * X.U.WorkspaceCompare xinerama compare with physical order Like the old xinerama workspace comparison, but order by physical location just like X.A.PhysicalScreens. Useful if using xinerama sort for statusbar together with physicalscreens.

3 2

telling xmonad that apparently huge screen == 2 screens
by Lara Michaels 04 Mar '10

04 Mar '10

Hi everyone, I am wondering if I can tell xmonad that what Xorg reports as a strangely wide 2560x1024 screen is in reality two physical 1280x1024 screens. (I am using a Matrox Dualhead2go, which emulates a very wide screen and then divides that signal onto two separate screens.) Can I tell xmonad what the real screen sizes are, so that maximization and, more generally, screen space management occurs at the correct level (ie, at the level of each 1280x1024 physical screen, rather than maximizing to take over the entire width of my monitor setup!). Can this be done? I used to be able to do this at the Xorg level when I was using a nvidia video card (using an option called "TwinViewXineramaInfoOveride"), but my new machine has Intel graphics and they don't seem to support this kind of magic... Can I solve it within xmonad? Many thanks for any help! ~lara

3 4

Minimize layout and Util.Loggers
by julien steinhauser 02 Mar '10

02 Mar '10

Hello, I'd like to know if a XMonad.Layout.Minimize user has already written a logger to have the name of a minimized window displayed in the status bar. The Minimize module is quite handy, but I don't want a taskbar with it, a few pixel on my Dzen bar would be fair enough, as I guess I won't have several windows minimized at the time time on the same workspace. Julien

1 0

Issue 377 in xmonad: Tabbed layout with long window title makes XMonad very slow
by codesite-noreply＠google.com 01 Mar '10

01 Mar '10

Status: New Owner: ---- New issue 377 by vandijk.roel: Tabbed layout with long window title makes XMonad very slow http://code.google.com/p/xmonad/issues/detail?id=377 What steps will reproduce the problem? 1. Switch to a tabbed layout 2. Point a browser to http://tutorial.happstack.com/src/ControllerBasic.hs Reproducible with both Firefox and Chromium. Upon navigating to the above URL XMonad uses 100% CPU for multiple seconds. This makes the system and XMonad in particular very unresponsive. This is very likely caused by an extremely long window title. The mentioned URL uses the entire source code of ControllerBasic.hs as the title of the page (which is probably a bug in itself). This title consists of 8340 characters. The browser then uses the page title as the window title which in turn is passed on to XMonad. What is the expected output? What do you see instead? I expect XMonad to not spend significantly more time on windows with a long title then on windows with a short title. On my system it takes over 5 seconds. This happens every time I change the layout to tabbed or switch the focus or workspace to one containing the evil window. It happens ONLY with tabbed layout. I created some dummy HTML files with titles of increasing length. The slowdown becomes apparent with titles over 1000 characters. The slowdown appears to be more than linear in terms of the window title length. The attached files test3, test4 and test5.html have title lengths of 500, 1000 and 2000 characters. Try viewing test5.html in a browser in tabbed layout and then switching between that window and another innocent one (terminal?) with [WIN]+[TAB] a few times to notice the problem. What version of the product are you using? On what operating system? xmonad-0.9.1 > uname -a Linux pcroel 2.6.31-gentoo-r10 #1 PREEMPT Tue Feb 23 12:46:16 CET 2010 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GenuineIntel GNU/Linux A simple workaround might be truncating window titles to a maximum of a few hundred characters. Attachments: xmonad.hs 7.1 KB test3.html 562 bytes test4.html 1.0 KB test5.html 2.0 KB -- 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 1

Issue 370 in xmonad: Xinerama, CycleWS & Empt workspaces
by codesite-noreply＠google.com 25 Feb '10

25 Feb '10

Status: New Owner: ---- New issue 370 by seansorrell: Xinerama, CycleWS & Empt workspaces http://code.google.com/p/xmonad/issues/detail?id=370 What steps will reproduce the problem? 1. On a Xinerama setup, pull up one workspace with a window, and one without 2. From the workspace with the window, use a keybinding to call XMonad.Actions.CycleWS nextScreen (or prevScreen) What is the expected output? What do you see instead? The cursor _should_ jump reliably to the screen without the window, but it only works about 3 times out of 10. Suggestion: move the cursor over a few extra pixels to ensure that it really is on the correct screen What version of the product are you using? On what operating system? xmonad 0.9 on Archlinux 64-bit nVidia 9800GT Attachments: xmonad.hs 5.7 KB xorg.conf 1.3 KB -- 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 2

Issue 375 in xmonad: keysResizeWindow doesn't always work
by codesite-noreply＠google.com 23 Feb '10

23 Feb '10

Status: New Owner: ---- New issue 375 by wei.hoo: keysResizeWindow doesn't always work http://code.google.com/p/xmonad/issues/detail?id=375 It seems that scaling a window down always work, but scaling up often fails. Here's my relevant keybinding: , ("M-<KP_Left>", withFocused (keysResizeWindow (-10, 0) (1%2, 1%2))) , ("M-<KP_Right>", withFocused (keysResizeWindow (10, 0) (1%2, 1%2))) , ("M-<KP_Up>", withFocused (keysResizeWindow (0, 10) (1%2, 1%2))) , ("M-<KP_Down>", withFocused (keysResizeWindow (0, -10) (1%2, 1%2))) I tested the operations on Google Chrome, Emacs, and urxvt: All four work on Chrome. M-U and M-R fail on urxvt; M-L and M-D work. M-U fail on Emacs; others work. What version of the product are you using? On what operating system? Darcs. Arch. Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". Please provide any additional information below. Attachments: xmonad.hs 9.1 KB -- 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 2

recompile, dzen and togglestruts
by julien steinhauser 22 Feb '10

22 Feb '10

Hello, On a fresh XMonad setup, I meet an issue and I'd like wise advices, wether I'm doing things correctly or not. I use two dzen, one for views, layout and title on the left and one for other things on right. The one on left is launched from within xmonad.hs via spawnpipe the one on right is lauched from my .xinitrc. If i make a change in xmonad.hs and want to recompile it, it compiles silently (no output with xmonad --recompile). All clients which were already here before the recompile won't cover the left dzen anymore after the recompile even with the mod-b shortcut (dzen stays on top) but they still cover the dzen on the right. All clients launched after the recompile behave the normal way, until I recompile ... My xmonad version : ~$ xmonad --version xmonad 0.9.1 (Source package xmonad and xmonad-contrib from Debian Sid) I attach my xmonad.hs I hope this message wasn't too confused. Julien

1 2

[patch] New extension: X.H.ScreenCorners
by Nils 22 Feb '10

22 Feb '10

Hi, I wrote a new extension today which will add KDE like screen corners to XMonad. See the documentation of the new module for more informations. http://www.n-sch.de/hdocs/xmonad-contrib/XMonad-Hooks-ScreenCorners.html Patch is attached. Nils Schweinsberg

2 4