March 2008 - xmonad - Haskell.org

ANNOUNCE: xmonad 0.7 released
by Don Stewart 11 Apr '08

11 Apr '08

http://xmonad.org The xmonad dev team is pleased to announce xmonad 0.7! The headlines: The 0.7 release of xmonad provides several improvements over 0.6, including improved integration with GNOME, more flexible "rules", various stability fixes, and of course, many new and interesting features in the extension library (general support for window decorations, utf8 support, scratch pad terminals, pointer control) and more! New GNOME support: Active, automated support for GNOME utilities. We know our users often like to use GNOME menus, tools and status bars, and we'd like to announce that xmonad actively supports GNOME! Extensions for communicating with and utilising gnome utilities come in the library suite, as well as extensive documentation and support. For more information see the GNOME/xmonad integration page on the wiki. A period of active development: In the past year, the xmonad development team received contributions from over 60 developers, making xmonad one of the largest window manager development teams around, and dwarfing other tiling window manager projects. Yet, at the same time, the core code base remains at around 1000 lines of code, with another 7000 lines in the extension library -- a significant achievment! Change logs: http://haskell.org/haskellwiki/Xmonad/Notable_changes_since_0.6 http://xmonad.org/changelog-0.7.txt http://xmonad.org/changelog-xmc-0.7.txt About: xmonad is a tiling window manager for X. Windows are arranged automatically to tile the screen without gaps or overlap, maximising screen use. Window manager features are accessible from the keyboard: a mouse is optional. xmonad is extensible in Haskell, allowing for powerful customisation. Custom layout algorithms, key bindings and other extensions may be written by the user in config files. Layouts are applied dynamically, and different layouts may be used on each workspace. Xinerama is fully supported, allowing windows to be tiled on several physical screens. Features: * Very stable, fast, small and simple. * Automatic window tiling and management * First class keyboard support: a mouse is unnecessary * Full support for tiling windows on multi-head displays * Full support for floating, tabbing and decorated windows * Full support for Gnome and KDE utilities * XRandR support to rotate, add or remove monitors * Per-workspace layout algorithms * Per-screens custom status bars * Compositing support * Powerful, stable customisation and reconfiguration * Large extension library * Excellent, extensive documentation * Large, active development team, support and community Get it! Information, screenshots, documentation, tutorials and community resources are available from the xmonad home page: http://xmonad.org The 0.7 release, and its dependencies, are available from hackage.haskell.org: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xmonad xmonad packages are available in the package systems of at least: Debian, Gentoo, Arch, Ubuntu, OpenBSD, NetBSD, FreeBSD, Gobo, NixOS, Source Mage, Slackware and 0.7 packages will appear in coming days (some are already available). On the fly updating to xmonad 0.7 is supported. You should be able to upgrade to xmonad 0.7 from 0.6 and earlier, transparently, without losing your session. Load the new code with mod-q and enjoy. Extensions: xmonad comes with a huge library of extensions (now more than 7 times the size of xmonad itself), contributed by viewers like you. Extensions enable pretty much arbitrary window manager behaviour to be implemented by users, in Haskell, in the config files. For more information on using and writing extensions see the webpage. The library of extensions is available from hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xmonad-contrib Full documentation for using and writing your own extensions: http://xmonad.org/contrib.html This release brought to you by the xmonad dev team: Spencer Janssen Don Stewart Jason Creighton David Roundy Brent Yorgey Devin Mullins Braden Shepherdson Roman Cheplyaka Lucas Mai Featuring code contributions from over 60 developers: Aaron Denney Adam Vogt Alec Berryman Alex Tarkovsky Alexandre Buisse Andrea Rossato Austin Seipp Bas van Dijk Ben Voui Brandon Allbery Chris Mears Christian Thiemann Clemens Fruhwirth Daniel Neri Daniel Wagner Dave Harrison David Glasser David Lazar Dmitry Kurochkin Dominik Bruhn Dougal Stanton Eric Mertens Ferenc Wagner Gwern Branwen Hans Philipp Annen Ivan Tarasov Jamie Webb Jeremy Apthorp Joachim Breitner Joachim Fasting Joe Thornber Joel Suovaniemi Juraj Hercek Justin Bogner Kai Grossjohann Karsten Schoelzel Klaus Weidner Mathias Stearn Mats Jansborg Matsuyama Tomohiro Michael Fellinger Michael Sloan Miikka Koskinen Neil Mitchell Nelson Elhage Nick Burlett Nicolas Pouillard Nils Anders Danielsson Peter De Wachter Robert Marlow Sam Hughes Shachaf Ben-Kiki Shae Erisson Simon Peyton Jones Stefan O'Rear Tom Rauchenwald Valery V. Vorotyntsev Will Farrington Yaakov Nemoy timthelion As well as the support of many others on the #xmonad and #haskell IRC channels, and the wider Haskell and window manager communities. Thanks to everyone for their support!

4 7

Floats always go to the current screen (Patch)
by Robert 06 Apr '08

06 Apr '08

When opening new floating windows on a multihead display, they will often unpredictably appear on a different screen to the one that currently has focus. Example: Bind a key to run 'gmrun'. Run gmrun from one screen and take note of which screen it appears on. Switch to another screen and do the same thing. gmrun will generally appear on the same screen each time. This seems unpredictable to me. I think new windows should always appear on the current workspace (unless it's transient perhaps). This allows me to, for example, choose which screen a new window appears on by switching to it first. In the current situation, I have to somehow remember where X prefers to launch an application and try to arrange my workspaces and screens such that the application will appear in the right location. This patch makes new float windows appear on the current screen as I think they should. The contrib patch makes contrib compatible with this change. I've undone some of the floating layer work in this patch. It seems the floating layer stuff was written explicitly to support the current way of placing floating windows. If there were good reasons for this functionality, please convince me my patch does the wrong thing. Otherwise, I think this patch has the benefit of being more predictable and simpler in code.

4 18

darcs patch: add SshAgent module, to start ssh-agent when needed.
by David Roundy 03 Apr '08

03 Apr '08

Hi all, I'm sending this rather than pushing, since we're close to a release. It's a new module to automatically start an ssh-agent, if one isn't running. I expect to find it useful. The reason for this is that the ordinary mechanism for starting a single ssh-agent for an X session doesn't seem to be working for me. And starting xmonad with `ssh-agent xmonad` does no good, because the ssh-agent exits as soon as I restart xmonad. David Sat Mar 29 11:49:11 CDT 2008 David Roundy <droundy(a)darcs.net> * add SshAgent module, to start ssh-agent when needed.

8 16

Issue 90 in xmonad: Restarting xmonad re-runs dzen/xmobar, which puts it at the top of the window stack
by codesite-noreply＠google.com 01 Apr '08

01 Apr '08

Issue 90: Restarting xmonad re-runs dzen/xmobar, which puts it at the top of the window stack http://code.google.com/p/xmonad/issues/detail?id=90 Comment #5 by lit...(a)hethrael.org: Workarounds: Open a new window in the master pane. (Moving an existing window to the master pane does not work, nor does creating a new non-master window.) Float a window. (Unfloating does not fix the z-order, though.) Use the tabbed layout. (If tabbed is in your list of layouts, simply switching to it will fix the z-order, then you can switch back to your desired layout.) -- 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 0

CycleRecentWS - gnome-like workspace switching
by Michał Janeczek 01 Apr '08

01 Apr '08

Hi, The attached patch provides a function to cycle through most recent workspaces with repeated presses of alt-tab (or similar). The order of workspaces previewed during the cycling is not affected, so it can be used to switch between 2 or 3 most commonly visited workspaces. It is possible to expand on this idea, for example by having alt-1 cycle between (most recently seen) emacs windows and alt-2 between browser windows, implementing a kind of "dynamic workspaces". There is some room for improvement - maybe it is possible to ask X about modkeys given only control mask, that way it would be marginally easier to use in config file. Regards, Michal

2 3

Add 'browser' to XConfig
by gwern0＠gmail.com 01 Apr '08

01 Apr '08

So I was recently contemplating my xmonad.hs (<http://haskell.org/haskellwiki/Xmonad/Config_archive/Gwern's_Config.hs>) and wondering whether my XMonad.Actions.Search and other extensions were yet in their ideal form, and it occurred to me: why do I have to keep writing "firefox"? I even have a shortcut defined, 'ff', which I use at least 8 times. Why am I constantly supplying Firefox as a parameter? Well, the answer is that those functions *need* a browser to use, they can't get away with getting it from somewhere else. There is no somewhere else, as there is no POSIX standard way of letting a user define a preferred browser (yes, I know about Debian's x-www-browser stuff, but that's Debian, and I know about environmental variables, but I don't think there's any standard $BROWSER like there is $HOME or $EDITOR). But of course, I'm not writing "urxvt" all over the place. So why not adopt the same solution? Add another slot, 'browser = "firefox"', and a keybinding. Two straight-forward lines in the core. I'm aware you can make arguments against this, but I don't think any apply to a browser field more than they apply to a terminal field. Firefox might not be installed; well, neither might XTerm - X.org is not always installed with all the trimmings, my Gentoo system certainly didn't. Users might not want to use it at all; many people don't use terminals either, as they prefer GUIs. Maybe users would prefer Konqueror; sure, but that's why you let it be changed easily - or do most people truly prefer that ugly antique Xterm? Perhaps this problem can be obviated with some sort of generic extension state? Perhaps, but I don't see any clear definition of what this change would be, and I don't see any code or even solid proposals. A bird in the hand... Would this be useful? I think so. If you search on the Haskell wiki for the string ""firefox"", you see a number of config hits besides mine, many instances that would be helped by browser in the config (eg <http://haskell.org/haskellwiki/Xmonad/Config_archive/Wfarr's_xmonad.hs>; note the 'myBrowser' definition). Would it be used by XMC? I think so. The terminal field is already being used by XMonad/Actions/Commands.hs and XMonad/Util/Run.hs, despite the relative reconditeness of the technique. -- gwern edition LLNL embassy aster SDIS Information ISN gun Mena ID

6 13

Andrea's screenshots and DecorationMadness
by Roman Cheplyaka 01 Apr '08

01 Apr '08

Ogedei @ IRC noted that some screenshots which are linked from haddock are not available. Precisely, these are arossato's screenshots. It's not hard to remove all broken links to screenshots, but the question arises concerning DecorationMadness module. Without screenshots it's utility becomes questionable. Sure some examples will go to Decorations haddock, but do we still need that module? -- Roman I. Cheplyaka (aka Feuerbach @ IRC)

4 3

Issue 169 in xmonad: Replace DecorationMadness with documentation
by codesite-noreply＠google.com 01 Apr '08

01 Apr '08

Issue 169: Replace DecorationMadness with documentation http://code.google.com/p/xmonad/issues/detail?id=169 New issue report by SpencerJanssen: We should document the decoration interfaces such that DecorationMadness is no longer needed. Issue attributes: Status: Accepted Owner: SpencerJanssen Labels: Type-Defect Priority-Medium Milestone-Release0.8 -- 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 0

Issue 145 in xmonad: Misplaced menus in openoffice with gtk widgets
by codesite-noreply＠google.com 31 Mar '08

31 Mar '08

Issue 145: Misplaced menus in openoffice with gtk widgets http://code.google.com/p/xmonad/issues/detail?id=145 Comment #5 by awesomelyawesome: Using Xinerama, I get the menus from an openoffice instance on my left monitor popping up on the lower right hand side of my right monitor. -- 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 0

Issue 145 in xmonad: Misplaced menus in openoffice with gtk widgets
by codesite-noreply＠google.com 31 Mar '08

31 Mar '08

Issue 145: Misplaced menus in openoffice with gtk widgets http://code.google.com/p/xmonad/issues/detail?id=145 Comment #4 by phabulosa: This problem also happened on dwm or awesome. wmii is ok. Other non-tiling WMs should be fine as well. Please keep me posted of any progress -- 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 0