December 2009 - xmonad

Small announce about the completion of the bluetile merge
by Don Stewart 11 Dec '09

11 Dec '09

http://xmonad.wordpress.com/2009/12/06/bluetile-branch-merged-into-xmonad/ Again, wonderful work Jan. And looking forward to XMonad.Config.Bluetile :) -- Don

12 24

How to make floats stay always on top?
by Leo Alekseyev 09 Dec '09

09 Dec '09

Hi All, I have trouble forcing floating windows (for instance, docks or cairo-clock) to always stay on top. That is, they stay on top until another floating window pops up, e.g. any Firefox dialog, or a window that I'm forcing to float with M-Button1. To reproduce: put only code from Layout.Monitor example page into the config file (below), start cairo-clock, go to Firefox and choose "save as", then click cancel. cairo-clock will disappear into the background. Is there a way to fix this?.. Thanks, --Leo import XMonad import XMonad.Layout.LayoutModifier import XMonad.Layout.Monitor clock = monitor { -- Cairo-clock creates 2 windows with the same classname, thus also using title prop = ClassName "Cairo-clock" `And` Title "MacSlow's Cairo-Clock" -- rectangle 150x150 in lower right corner, assuming 1280x800 resolution , rect = Rectangle (1280-150) (800-150) 150 150 -- avoid flickering , persistent = True -- make the window transparent , opacity = 0.6 -- hide on start , visible = False -- assign it a name to be able to toggle it independently of others , name = "clock" } myLayouts = ModifiedLayout clock $ tiled ||| Mirror tiled ||| Full where tiled = Tall nmaster delta ratio nmaster = 1 ratio = 1/2 delta = 3/100 main = do xmonad $ defaultConfig { manageHook = manageMonitor clock , layoutHook = myLayouts }

1 0

[patch] X.A.OnScreen
by Nils 08 Dec '09

08 Dec '09

Hey, I wrote a patch for my X.A.OnScreen module. onScreen will now take any function that modifies the stack and run it on a given screen. Therefor this is far more general than the previous version and should work correctly for basicly everything. As a result, greedyViewOnScreen is now working correctly and two new functions "toggle(Greedy)OnScreen" have been added since I love that one. :) Sadly I had to reimplement the toggleOrView function since the X.A.CycleWS runs inside the X monad (although there is absolutly *no* resaon at all for this...) and I'm too lazy to write a patch for that. The "end user" functions like viewOnScreen etc. didn't change in their use, of course. Nils / McManiaC

2 2

3 issues changed in xmonad
by codesite-noreply＠google.com 08 Dec '09

08 Dec '09

Updates: Labels: Milestone-Release1.0 Comment by SpencerJanssen: (No comment was entered for this change.) Affected issues: issue 313: Merge contrib's isFullscreen and doFullFloat to core http://code.google.com/p/xmonad/issues/detail?id=313 issue 314: Investigate merging SmartBorders to core http://code.google.com/p/xmonad/issues/detail?id=314 issue 332: Merge isDialog from Hooks.ManageHelpers into core http://code.google.com/p/xmonad/issues/detail?id=332 -- You received this message because you are listed in the owner or CC fields of these issues, or because you starred them. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

CORE documentation patch: remove references to non-existent dynamicLogDzen function (fixes #323)
by Brent Yorgey 08 Dec '09

08 Dec '09

Thu Nov 26 00:39:08 EST 2009 Brent Yorgey <byorgey(a)cis.upenn.edu> * man/xmonad.hs: remove reference to deprecated 'dynamicLogDzen' function

2 1

darcs patch: Main.hs +--verbose-version flag
by gwern0＠gmail.com 07 Dec '09

07 Dec '09

Sat Nov 28 09:48:40 EST 2009 gwern0(a)gmail.com * Main.hs +--verbose-version flag This resolves http://code.google.com/p/xmonad/issues/detail?id=320 by adding a --verbose-version option yielding output like "xmonad 0.9 compiled by ghc 6.10 for linux/i386"

2 1

darcs patch: Generalize the type of (<+>). It can be used for keybi...
by Adam Vogt 07 Dec '09

07 Dec '09

Sat Dec 5 18:36:11 EST 2009 Adam Vogt <vogt.adam(a)gmail.com> * Generalize the type of (<+>). It can be used for keybindings too.

8 13

Re: Issue 320 in xmonad: Make --version more informative
by codesite-noreply＠google.com 07 Dec '09

07 Dec '09

Updates: Labels: Type-Enhancement Priority-Low Component-Core Usability Comment #1 on issue 320 by byorgey: Make --version more informative http://code.google.com/p/xmonad/issues/detail?id=320 (No comment was entered for this change.) -- 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 3

PoC: FlexibleRead -- layout settings that survive a layoutHook change
by Tomáš Janoušek 07 Dec '09

07 Dec '09

Hello, I'd like to announce a proof of concept I wrote over the weekend. In my previous mail (about dynamic workspace names) I mentioned that WorkspaceDir settings are lost whenever the layout hook changes, even if it is the outermost layout modifier. Realizing that the layout is essentially a tree, I walked up to a whiteboard and found a solution. What I ended up doing was that I have a typeclass for reading and writing a layout from/to a tree, and instances for ModifiedLayout, NewSelect and generic layouts. This alone solves the problem of outermost modifiers, since the tree can always be read, and I call reads for each modifier separately, replacing it from a default value if it fails. For all this to work, the Read instance for my modifier needs to have a default value at hand, and this is done by a snippet of template haskell that defines a Read instance for the very type of a particular layout and provides the default value to the reading function. Without TH, one would have to write the complete type into the instance head manually. Finally, an algorithm that takes the old layout tree, new layout tree, and tries to pass the configuration from the old one to the new one, if it changed, is plugged into the Read instance. The algorithm is accompanied by a few quickcheck properties that ensure that certain simple modifications are fully recoverable: - change of the order of layouts in NewSelect, as long as they are distinguishable (which mouseResizableTiled and its mirrored variant are not, but I'll send a patch for this later), - change of one of the outermost modifiers, as long as it's not anywhere else in the tree (this probably be improved), - addition of a layout (a layout chain, in fact). It uses a very crude heuristic that can be certainly made better. The code resides in my config repository at [1]. The configuration is pretty simple, just add a flexibleRead in front of the layout, and then have flexibleReadInstance derive the instance for you. Have a look at my xmonad.hs if in trouble. [1] http://anna.fi.muni.cz/~xjanous3/darcs/xmonad-conf/ It is just a proof of concept, it is quite ugly, and I'm hoping for some insightful comments. One that comes to my mind is that we can at least get rid of template haskell if xmonad core used some other Read type class that had the ability to provide a default value (but hey, isn't is a nice use of it after all? :-)). Regards, -- Tomáš Janoušek, a.k.a. Liskni_si, http://work.lisk.in/

1 0

More decoration
by Jan Vornberger 06 Dec '09

06 Dec '09

Hi! A quick information e-mail: I just pushed (Spencer gave me access to xmonad contrib, thx!) some patches containing Bluetile's decoration. These are: Sun Nov 29 01:24:16 CET 2009 Jan Vornberger <jan.vornberger(a)informatik.uni-oldenburg.de> * A decoration with small buttons and a supporting module The decoration that is used for the floating/stacking layout with little 'buttons' to minimize, maximize and close the window. Sun Nov 29 01:34:31 CET 2009 Jan Vornberger <jan.vornberger(a)informatik.uni-oldenburg.de> * Decoration that allows to switch the position of windows by dragging them onto each other. A decoration that is used in all the tiled layouts. Patch description pretty much says it. This should work fairly well in combination with all sorts of layouts. Sun Nov 29 01:45:06 CET 2009 Jan Vornberger <jan.vornberger(a)informatik.uni-oldenburg.de> * Module to ensure that a dragged window always stays in front of all other windows In my branch I modified the core for this, but I figured out a way to do it as a contrib module: In a dual-head setup you can drag windows from one screen to another, but the stacking order might be such, that the dragged window disappears behind the windows on the other screen. This workaround makes sure that the dragged window is always in front of everything else. With these three patches my process of porting Bluetile from my branch over to xmond mainline is actually complete! I can now build Bluetile from xmonad mainline alone - yay! :-) Cheers! Jan

5 4