August 2009 - xmonad - Haskell.org

darcs patch: Add a way to update the modifier in X.L.LayoutModifier
by Daniel Schoepe 05 May '10

05 May '10

Sat Aug 22 23:39:58 CEST 2009 Daniel Schoepe <daniel.schoepe(a)gmail.com> * Add a way to update the modifier in X.L.LayoutModifier This patch adds the possibility to update the state of a layout modifier when modifying the underlying layout before it is run(i.e. using modifyLayout). The modified state is also passed to the subsequent call of redoLayout, whose return takes precedence if both functions return modified states of the layout modifier.

6 9

Compile-time verification of keymaps
by Gwern Branwen 28 Mar '10

28 Mar '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 So today I edited into my xmonad.hs a binding to the Isohunt.com XMonad.Actions.Search engine for convenience. I naturally chose xK_i for the bound key. When I reloaded, I was surprised to see that mod-i failed to do as it was supposed to. Trying it again, it brought up irssi. That was when I realized mod-i had already been bound in my xmonad.hs, to runOrRaise for irssi, and that the irssi binding happened to be later in the list and so it quietly overwrote the Isohunt binding. After picking a new & unused key, I began reflecting on this. Certainly, this is expected behavior if you're familiar with Data.Map. fromList will do that - a list may have multiple values for a single key (such as xK_i) and the last value wins. But I think in an xmonad.hs, the context is somewhat different. There the semantics are somewhat different. We use 'M.fromList [stuff, more stuff, and the rest]' syntax because Haskell supports list syntax, and it makes life easier on the user to use such a common method. But do we *really* mean to say that it is a sensible thing to bind the same key to multiple contradictory definitions? It just so happens that [xK_i isohunt, xK_i irssi] is equivalent to a destructive update style of 'i = isohunt; i = irssi' when fed through the Map functions. So I thought to myself that maybe there was some static way of specifying a list without duplicates we could use in xmonad.hs. It would be nice to know that one cannot run xmonad.hs with inconsistent sets of bindings*. This checking would, even better, be done at compile-time so one could verify this by simply loading in GHCi (good for everyone who routinely reloads in Emacs or Vim). How to do this? Someone in #haskell suggested extensible records, but that sounds quite difficult. Another approach would be to scrap the static requirement, and simply provide the user a redefined 'fromList' which runs something like 'let x = map fst list in nub x == x' and does something if there are duplicates (calls error, spawns xmessage, etc.) I decided to try a variant of the latter at compile-time, using Template Haskell. I got fairly far with the help of mmorrow, but I didn't actually succeed. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREKAAYFAkkgYvgACgkQvpDo5Pfl1oLE3gCgkuHMlUO1+YT4oEFLzhHqmeuB QA4An3X72j1z+StumSOmnTXlTJhHeTft =fBDz -----END PGP SIGNATURE----- The idea is that one should be able to do something like this in xmonad.hs > '{-# LANGUAGE TemplateHaskell #-} > import XMonad.Utils.VerifyKeys > .... > myKeys conf@(XConfig {modMask = m}) = M.fromList $(uniqueTupleListQ [ -- rebind standard actions > ((m .|. shiftMask,xK_p), shellPrompt greenXPConfig) > , ((m, xK_d), raiseBrowser) ] ) VerifyKeys looks something like this: > {-# LANGUAGE TemplateHaskell #-} > module XMonad.Utils.VerifyKeys where > > import Data.List(nub) > import qualified Data.Map > import Language.Haskell.TH.Lib > import Language.Haskell.TH.Syntax > > uniqueTupleListQ :: (Eq a, Lift a, Lift b) => [(a, b)] -> ExpQ > uniqueTupleListQ xs = let ys = map fst xs > ns = nub ys > in case ys == ns of > False -> fail "uniqueTupleListQ: List has conflicting entries." > True -> lift xs The idea is that since we know the keymap at compile-time, we pass it, before it gets turned into a Map (and the relevant information lost), we analyze the list. 'fail' aborts the compilation if the list is bad. You can easily test this out in a different module with some simple expressions: > keymap1, keymap2 :: [(Char, String)] > keymap1 = $(uniqueTupleListQ [('a', "foo"), ('b', "bar")] ) > keymap2 = $(uniqueTupleListQ [('a', "foo"), ('b', "bar"), ('c', "bar"), ('a', "quux")] ) Compiling, this gives us something like this: > [1 of 2] Compiling Tmp ( Tmp.hs, Tmp.o ) > [2 of 2] Compiling Main ( xmonad.hs, xmonad.o ) > Loading package base ... linking ... done. > Loading package array-0.1.0.0 ... linking ... done. > Loading package packedstring-0.1.0.0 ... linking ... done. > Loading package containers-0.1.0.1 ... linking ... done. > Loading package pretty-1.0.0.0 ... linking ... done. > Loading package template-haskell ... linking ... done. > > xmonad.hs:113:12: uniqueTupleListQ: List has conflicting entries. Line 133 is keymap2. If we remove '('a', "quux")', which conflicts with the very first entry, we get: > [1 of 2] Compiling Tmp ( Tmp.hs, Tmp.o ) > [2 of 2] Compiling Main ( xmonad.hs, xmonad.o ) > Loading package base ... linking ... done. > Loading package array-0.1.0.0 ... linking ... done. > Loading package packedstring-0.1.0.0 ... linking ... done. > Loading package containers-0.1.0.1 ... linking ... done. > Loading package pretty-1.0.0.0 ... linking ... done. > Loading package template-haskell ... linking ... done. > Linking foo ... Now, this seems to be exactly what we want, doesn't it? But ultimately I had to admit failure. Template Haskell has a number of restrictions and omissions that make it unfeasible to use. For starters: If we apply uniqueTupleList to an actual keymap (like mine), we discover that uniqueTupleList's constraints are unworkable. Per the type sig, we need 'Lift b', the second half of each tuple in the key list. But XMonad requires b to be a X (), and X () is not instantiated for Lift**. Were it, we would still need Lift instances for Word64 and also CUInt. Lift instances probably wouldn't be too hard to write. The real killer, from an xmonad.hs perspective, is the module restrictions. Fundamentally, one *cannot* use inside a $() anything defined in the same file. {modMask = m}? Nope. greenXPConfig? Nope. 'term = XMonad.terminal conf'? Nope. And so on. It is a minimal set of bindings indeed which only makes use of literals and imported functions. So until Template Haskell improves, that avenue seems to be out. I'm not sure where to go from here. Had Template Haskell worked out, the path would've been easy, a matter of having users make a relatively small modification to their xmonad.hs, and perhaps avoiding entirely TH syntax. Does anyone have a better approach, or is this a foolish thing to want static safety in? ksf suggested that Yi has a combinator approach to keybindings which could solve it, but I am unsure how that works or could be adapted for XMonad.*** * Obviously the consistency is only valuable _in_ a specific Map; if we insisted that all Maps be consistent, then we couldn't override the default Map with our own. ** I may be misinterpreting the type error; possibly we actually need Lift for (X()) *** I'm cc'ing yi-devel since I suspect the topic may be of interest. -- gwern

5 7

darcs patch: Replace custom forever_ with library equivalent
by Daniel Schoepe 27 Mar '10

27 Mar '10

Replaced a custom forever implementation in Main.hsc by the equivalent from the standard libraries. I guess it was legacy code, since forever wasn't in Control.Monad in ghc 6.6 as far as I know. Wed Jan 14 22:55:56 CET 2009 Daniel Schoepe <asgaroth_(a)gmx.de> * Replaced custom forever_ by library function New patches: [Replaced custom forever_ by library function Daniel Schoepe <asgaroth_(a)gmx.de>**20090114215556] { hunk ./XMonad/Main.hsc 146 userCode $ startupHook initxmc -- main loop, for all you HOF/recursion fans out there. - forever_ $ prehandle =<< io (nextEvent dpy e >> getEvent e) + forever $ prehandle =<< io (nextEvent dpy e >> getEvent e) return () where hunk ./XMonad/Main.hsc 150 - forever_ a = a >> forever_ a - -- if the event gives us the position of the pointer, set mousePosition prehandle e = let mouse = do guard (ev_event_type e `elem` evs) return (fromIntegral (ev_x_root e) } Context: [Call logHook as the very last action in windows Spencer Janssen <spencerjanssen(a)gmail.com>**20081209233700 Ignore-this: 4396ad891b607780f8e4b3b6bbce87e ] [Accept inferior crossing events. This patch enables fmouse-focus-follows-screen Spencer Janssen <spencerjanssen(a)gmail.com>**20081205045130 Ignore-this: 3ac329fb92839827aed0a4370784cabd ] [Tile all windows at once Spencer Janssen <spencerjanssen(a)gmail.com>**20081118074447] [Factor rational rect scaling into a separate function Spencer Janssen <spencerjanssen(a)gmail.com>**20081118072849] [Change screen focus by clicking on the root window. Spencer Janssen <spencerjanssen(a)gmail.com>**20081106224031 This is a modification of a patch from Joachim Breitner. ] [Fix #192. Spencer Janssen <spencerjanssen(a)gmail.com>**20081021220059] [select base < 4 for building on ghc 6.10 Adam Vogt <vogt.adam(a)gmail.com>**20081013214509] [add killWindow function Joachim Breitner <mail(a)joachim-breitner.de>**20081005001804 This is required to kill anything that is not focused, without having to focus it first. ] [add'l documentation Devin Mullins <me(a)twifkak.com>**20080927234639] [Regression: ungrab buttons on *non* root windows Spencer Janssen <spencerjanssen(a)gmail.com>**20081007214351] [Partial fix for #40 Spencer Janssen <spencerjanssen(a)gmail.com>**20081007212053 Improvements: - clicking on the root will change focus to that screen - moving the mouse from a window on a screen to an empty screen changes focus to that screen The only remaining issue is that moving the mouse between two empty screens does not change focus. In order to solve this, we'd have to select motion events on the root window, which is potentially expensive. ] [Track mouse position via events received Spencer Janssen <spencerjanssen(a)gmail.com>**20081007203953] [Fix haddock Spencer Janssen <spencerjanssen(a)gmail.com>**20081007094641] [Move screen locating code into pointScreen Spencer Janssen <spencerjanssen(a)gmail.com>**20081007094207] [Make pointWithin a top-level binding Spencer Janssen <spencerjanssen(a)gmail.com>**20081007090229] [sp README, CONFIG, STYLE, TODO gwern0(a)gmail.com**20080913024457] [Use the same X11 dependency as xmonad-contrib Spencer Janssen <spencerjanssen(a)gmail.com>**20080921061508] [Export focusUp' and focusDown' -- work entirely on stacks Spencer Janssen <spencerjanssen(a)gmail.com>**20080911214803] [add W.shiftMaster, fix float/tile-reordering bug Devin Mullins <me(a)twifkak.com>**20080911053909] [TAG 0.8 Spencer Janssen <spencerjanssen(a)gmail.com>**20080905195412] [Spelling. Any bets on how long this has been there? Spencer Janssen <spencerjanssen(a)gmail.com>**20080905195211] [Bump version to 0.8 Spencer Janssen <spencerjanssen(a)gmail.com>**20080905194225] [Remove obsolete comments about darcs X11 Spencer Janssen <spencerjanssen(a)gmail.com>**20080905194915] [Recommend latest packages rather than specific versions Spencer Janssen <spencerjanssen(a)gmail.com>**20080905194837] [Also remove -optl from the executable section Spencer Janssen <spencerjanssen(a)gmail.com>**20080820210023] [-optl-Wl,-s is not needed with recent Cabal versions Spencer Janssen <spencerjanssen(a)gmail.com>**20080820204102] [Haddock links Malebria <malebria(a)riseup.net>**20080601212515] [Haddock syntax for enumeration Malebria <malebria(a)riseup.net>**20080601204951] [I prefer the spencerjanssen(a)gmail.com address now Spencer Janssen <spencerjanssen(a)gmail.com>**20080714202650] [Raise windows in the floating layer when moving or resizing Trevor Elliott <trevor(a)galois.com>**20080521215057] [add currentTag convenience function Devin Mullins <me(a)twifkak.com>**20080511224258] [Make Mirror a newtype Spencer Janssen <sjanssen(a)cse.unl.edu>**20080508104640] [Comments Spencer Janssen <sjanssen(a)cse.unl.edu>**20080507013122] [Break long line Spencer Janssen <sjanssen(a)cse.unl.edu>**20080507012608] [Style Spencer Janssen <sjanssen(a)cse.unl.edu>**20080507012519] [Simplify Spencer Janssen <sjanssen(a)cse.unl.edu>**20080507011309] [Overhaul Choose, fixes issue 183 Spencer Janssen <sjanssen(a)cse.unl.edu>**20080506220809] [Remember if focus changes were caused by mouse actions or by key commands Klaus Weidner <kweidner(a)pobox.com>**20080502175603 If the user used the mouse to change window focus (moving into or clicking on a window), this should be handled differently than focus changes due to keyboard commands. Specifically, it's inappropriate to discard window enter/leave events while the mouse is moving. This fixes the bug where a fast mouse motion across multiple windows resulted in the wrong window keeping focus. It's also helpful information for contrib modules such as UpdatePointer - it's supposed to move the mouse pointer only in response to keyboard actions, not if the user was moving the mouse. ] [Wibble Spencer Janssen <sjanssen(a)cse.unl.edu>**20080506203840] [Added doShift function for more user-friendly hooks Ivan N. Veselov <veselov(a)gmail.com>**20080506185757] [use named colours. fixes startup failure on the XO Don Stewart <dons(a)galois.com>**20080502210149] [Set focus *after* revealing windows Spencer Janssen <sjanssen(a)cse.unl.edu>**20080407222559] [Reveal windows after moving/resizing them. Spencer Janssen <sjanssen(a)cse.unl.edu>**20080407220756 This should reduce the number of repaints for newly visible windows. ] [Hide newly created but non-visible windows (fixes bug #172) Spencer Janssen <sjanssen(a)cse.unl.edu>**20080430014012] [formatting, eta expansion Don Stewart <dons(a)galois.com>**20080418184337] [XMonad.ManageHook: add 'appName', another name for 'resource' Lukas Mai <l.mai(a)web.de>**20080406012006] [XMonad.ManageHook: make 'title' locale-aware; haddock cleanup Lukas Mai <l.mai(a)web.de>**20080406011338 The code for 'title' was stolen from getname.patch (bug #44). ] [XMonad.Main: call setlocale on startup Lukas Mai <l.mai(a)web.de>**20080406011234] [floats always use current screen (with less bugs) robreim(a)bobturf.org**20080405135009] [XMonad.Operations: applySizeHint reshuffle Lukas Mai <l.mai(a)web.de>**20080404215615 Make applySizeHints take window borders into account. Move old functionality to applySizeHintsContents. Add new mkAdjust function that generates a custom autohinter for a window. ] [XMonad.Layout: documentation cleanup Lukas Mai <l.mai(a)web.de>**20080404215444] [Remove gaps from the example config Spencer Janssen <sjanssen(a)cse.unl.edu>**20080329232959] [Remove gaps Spencer Janssen <sjanssen(a)cse.unl.edu>**20080325091526] [TAG 0.7 Spencer Janssen <sjanssen(a)cse.unl.edu>**20080329210249] Patch bundle hash: ef4a14f0e22b06712aac9975c8df956a9b2846ba

7 11

Call for xmonad.hs
by Gwern Branwen 16 Jan '10

16 Jan '10

Hi everyone. So a while ago we were discussing how to improve defaults and what sorts of types and functions XM and XMC could provide which encapsulate common behavior, when Devon asked me what exactly I saw being repeated (besides the 2 or 3 examples I provided), and it occurred to me that I really didn't know. There're ~30 xmonad.hs's here <http://haskell.org/haskellwiki/Xmonad/Config_archive>, but perhaps 1/3 to 1/2 are obsolete or don't compile with darcs XM/XMC (at a very rough guess). I'd like more. So here's what I would greatly appreciate everyone doing: 1) Upload your config 2) If you've uploaded your config, update it! 3) If you use someone else's config, why not mention it? I'd appreciate knowing who's using what, so I can count the popular configurations proportionately* 4) If you don't want to do any of 1-3, perhaps you could email me privately with your config? Thanks in advance all. * I think it's fair to say that if 10 people are using a particular xmonad.hs, and there's a simplification which could be made, that change should count 10x -- gwern ANZUS nuclear Lebed .ch Domination .tm top Amherst USSS Hugo

10 27

Changing module headers
by Gwern Branwen 20 Dec '09

20 Dec '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 So I mentioned a while ago I meant to go over XMC using the 'sim' tool (with an invocation like sim_mira `find . -name "*.hs"` - I discovered recently that it had Miranda support, which means quasi-Haskell support). But the results are littered with comments. Particularly obnoxious are the module headers, in part because they all seem to use '--' comments even if they cover dozens of lines. Would anyone object if I were to edit those to use {- -} style (and push those edits without review)? - -- gwern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREKAAYFAko+xRkACgkQvpDo5Pfl1oJuNwCgi4IhXrPLMdOHlWdReKTcMH2f GbUAn0pT7fM9dnLYW0acoaQrVKc2H51w =ngUp -----END PGP SIGNATURE-----

5 9

Re: [xmonad] startup programs
by Bozelos Dimitris 22 Sep '09

22 Sep '09

Hello everyone, thanks for your replies and sorry for the late reply from my part, I didn't have internet access for looong time. Thanks a lot Olivier, that's the closest to what I want to do. I have some questions: 1) Sometimes programs are placed in different order than asked in the startup hook, probably because of different startup times. Also sometimes one program might need another to successfully run. So is there a way to have xmonad to wait until one program has fully started before proceeded to the next? In my case something like myStartupHook = do spawn "xterm -e '/usr/bin/jackd -R -dalsa -r48000'" a command for " wait until jackd has ran " or " wait 5 seconds " and then spawn "xterm -e 'chuck --loop --srate48000'" 2) Is there a way to run a terminal and a program from a specified directory? Like if I would do in a terminal : 1) cd "path" 2) emacs - so that emacs starts with "path" as its default directory 3) With some programs with no graphical interface that print messages to the terminal like jackd as above, when I startup with the above way it's not really the same as if I would call it from a terminal. If it terminates for any reason it dissapears while if I had ran it from a terminal the terminal would stay and I could have seen any error messages. Anybody knows if it can be otherwise? 4) I couldn't really find out how to move a program or terminal to a desktop, can you please make your example more precise? Let's say I want to run 2 instances of emacs and move the first to desktop 1 and the second to desktop 2. How would I do this? Thanks, Dimitris >You can launch each terminal you want to put on the desktop FooBar with >the command "xterm -name gotoFooBar" and add the following manageDocks >to your xmonad.hs: > >myManageHook = manageDocks <+> composeAll > [ title =? "gotoFooBar" --> doF (W.shift "FooBar") > ] > >Moreover, you can know the class and the name of an X windows with the >command xprop. > >Cheers, > >Olivier >>Hello everyone, >>After making the usual statement that I'm completely new to xmonad and I have no clue about haskell, I have loved xmonad and I have a question to find out if I can make more out of it: >>I'm using fedora linux with xmonad and i'm preparing for a music performance. I need at the concert to be able to startup my laptop and if possible to have everything up and running, without having to switch between desktops and run terminals & programs. This means that I don't only want to run some programs at startup (which could be done in the usual way for linux with a startup script - although I don't really know much about it) but I want the programs to be ran from terminals and be placed in the desktops in the way I would do manually after launching xmonad. >>Is this possible with xmonad? Any simple tutorials available on this? Thanks, >>Dimitris ___________________________________________________________ Χρησιμοποιείτε Yahoo!; Βαρεθήκατε τα ενοχλητικά μηνύματα (spam); Το Yahoo! Mail διαθέτει την καλύτερη δυνατή προστασία κατά των ενοχλητικών μηνυμάτων http://login.yahoo.com/config/mail?.intl=gr

7 9

xmonad from gnome-session-2.26
by Joachim Breitner 20 Sep '09

20 Sep '09

Hi, If you want to use xmonad from gnome-session-2.26, the correct way seems to be to specify # gconftool-2 -s /desktop/gnome/session/required_components/windowmanager xmonad --type string This unfortunately has the effect that gnome-session waits a few seconds for the window manger (now xmonad) to register via dbus, see http://live.gnome.org/SessionManagement/GnomeSession xmonad does not support the gnome-session protocol, but you can work around the delay with this code in xmonad.hs import XMonad [...] import System.Environment import System.Cmd [...] main = do env <- getEnvironment case lookup "DESKTOP_AUTOSTART_ID" env of Just id -> do rawSystem "dbus-send" ["--session","--print-reply=string","--dest=org.gnome.SessionManager","/org/gnome/SessionManager","org.gnome.SessionManager.RegisterClient","string:xmonad","string:"++id] return () Nothing -> return () xmonad $ defaultConfig { [...] -- simple stuff } I guess some stuff can be improved about this, such as using the DBus package from hackage, but it’s a start. Greetings, Joachim -- Joachim Breitner e-Mail: mail(a)joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nomeata(a)joachim-breitner.de

5 5

Bluetile
by gwern0＠gmail.com 05 Sep '09

05 Sep '09

Resources: - Original thread/ANN: http://thread.gmane.org/gmane.comp.lang.haskell.xmonad/7458/ - Jan Vorberger's OP: http://article.gmane.org/gmane.comp.lang.haskell.xmonad/7458 > "I'm planning to decide on a somewhat fixed configuration of XMonad, probably in combination with Gnome as a DE, and then trying to make this functionality available via mouse commands that - hopefully - will be easy to pick up.<br> > I also want to completely rework the whole floating layer thing, as it seems to me to be a fairly foreing [sic] concept for a newcomer and it's awkward to use. My current idea is to instead use a floating layout algorithm, that could work similiar [sic] to a conventional window manager. It could even be set as the default layout algorithm. That way, the WM could almost be a 'drop-in' replacement for - let's say Metacity - greeting the user with the familiar concept of manipulating windows and then leading him to the tiling paradigm once he switches the layout." Jan later [wrote](http://article.gmane.org/gmane.comp.lang.haskell.xmonad/7495) that > "@Don: I will definitely try to contribute back changes and improvements, if I can. Once I start implementing I will also make my repository available for others to try out. Thx for offering assistance, I might come back to that later." But given that Bluetile has been done a while, I guess we'll just have to content ourselves with the repos. - A PDF presentation of some sort is available at http://parsys.informatik.uni-oldenburg.de/theses/docs/bluetile_zwischenvort… - Google Translate link, may or may not work: http://translate.google.com/translate?hl=en&sl=de&u=http://parsys.informati… The actual code seems to be broken up into 4 packages; everything is BSD3 so no concerns about reuse: - bluetilutils: http://hackage.haskell.org/package/bluetileutils (Darcs repo: http://tuvok.home.dyndns.org/bluetile-repos/bluetileutils down?) A package of 3 Gtk2hs executables: i. bluetiledock ii. bluetilemockwin iii. bluetilegreet - xmonad-bluetilebranch: http://hackage.haskell.org/package/xmonad-bluetilebranch (I have no local repo for this, although it was presumably at http://tuvok.home.dyndns.org/bluetile-repos/xmonad-bluetilebranch ) - xmonad-contrib-bluetilebranch: http://hackage.haskell.org/package/xmonad-contrib-bluetilebranch (same comment for repo) - bluetile: http://hackage.haskell.org/package/bluetile (repo: http://tuvok.home.dyndns.org/bluetile-repos/bluetile ) Now, looking at the code (bearing in mind I am only reading and haven't compiled/run anything yet): # bluetileutils ## bluetiledock This creates a minimalistic strut app. It supports 14 buttons/commands: - switch to workspaces 0-9 - 4 commands to switch to floating/tiled1/tiled2/fullscreen (presumably tiled1 and tiled2 = 2 windows each on 1/2 screen split horizontal & vertical) Interesting is how bluetiledock achieves this functionality, how it makes xmonad actually do something - it seems to be using a X-based method of IPC, in which a integer is stored in an X atom and xmonad then grabs it and does something with it: ~~~~{.haskell} sendCommandX :: Int -> IO () sendCommandX com = do d <- X.openDisplay "" rw <- X.rootWindow d $ X.defaultScreen d a <- X.internAtom d "XMONAD_COMMAND" False X.allocaXEvent $ \e -> do XE.setEventType e X.clientMessage XE.setClientMessageEvent e rw a 32 (fromIntegral com) XE.currentTime X.sendEvent d rw False X.structureNotifyMask e X.sync d False ~~~~ ## bluetilegreet A splashscreen/help; checks for empty file ~/.bluetilegreet and if it exists, makes it and runs. It then basically displays the XML contents of bluetilegreet.glade, which run something like: ~~~~{.xml} <property name="label" translatable="yes">Quickstart: Open a few windows and notice that you are currently in the traditional layout mode, known from most other window managers. To start tiling, switch to another layout in one of these ways:</property> <property name="wrap">True</property> </widget> </child> <child> <widget class="GtkLabel" id="label3"> <property name="visible">True</property> <property name="label" translatable="yes">* Using the dock on the left (buttons A, S, D or F), * pressing the middle mouse button while holding down the Windows key or * using the keyboard shortcuts Win+A, Win+S, Win+D or Win+F .</property> </widget> <packing> <property name="top_attach">1</property> <property name="bottom_attach">2</property> </packing> </child> <child> <widget class="GtkLabel" id="label4"> <property name="visible">True</property> <property name="label" translatable="yes">You should be fine exploring the tiling paradigm with your mouse alone, but to get the most out of it you might want to look at the keyboard shortcuts at some point. They are documented on Bluetile's website.</property> <property name="wrap">True</property> ~~~~ It might be a good idea to have something similar for XMonad; it's not like it really matters if we dump an empty hidden file in ~/.xmonad ## bluetilemockwin No idea. It creates some sort of widget with the RGB color specified as 3 ints. Grep doesn't seem to show up any use in the main bluetile repo. ~~~~{.haskell} main :: IO () main = do args <- getArgs progName <- getProgName if length args /= 3 then putStrLn $ "Usage: " ++ progName ++ " 0 0 65535" else let r = read $ args !! 0 g = read $ args !! 1 b = read $ args !! 2 in showMockWin (Color r g b) showMockWin :: Color -> IO () showMockWin c = do initGUI window <- windowNew onDestroy window mainQuit widgetModifyBg window StateNormal c widgetShowAll window mainGUI ~~~~ # xmonad-contrib-bluetilebranch Without a repo, it's hard to know exactly what's changed. But by my count, this XMC fork adds the following modules: - XMonad.Actions.BluetileCommands defines `[(String, X ())]`, which seem to support the 14 commands used by the dock, and 4 others (quit, quit-and-start-metacity, increase master, decrease master) - XMonad.Actions.WindowMenu much as it sounds, supporting the following commands: ~~~~{.haskell} actions = [ ("Cancel menu", return ()) , ("Close" , kill) , ("Maximize" , sendMessage $ maximizeRestore w) , ("Minimize" , sendMessage $ MinimizeWin w) ] ++ [ ("Move to workspace " ++ tag, windows $ W.shift tag) | tag <- tags ] ~~~~ - XMonad.Hooks.BluetileDock - XMonad.Hooks.CustomRestart adequately summarized by a snippet ~~~~{.haskell} a <- io $ internAtom d "XMONAD_CUSTOM_RESTART" False when (mt == a) $ do restart prog True ~~~~ - XMonad.Hooks.EventHook Old code? Seems to've been removed in darcs XMC - XMonad.Hooks.RestoreMinimized - XMonad.Hooks.WorkspaceByPos No idea. What I did notice is that it looks like it could use the Maybe monad! ~~~{.haskell} needsMoving :: Window -> X (Maybe WorkspaceId) needsMoving w = withDisplay $ \d -> do -- only relocate windows with non-zero position wa <- io $ getWindowAttributes d w if ((wa_x wa) == 0) && ((wa_y wa) == 0) then return Nothing else do ws <- gets windowset sc <- fromMaybe (W.current ws) <$> pointScreen (fi $ wa_x wa) (fi $ wa_y wa) maybeWkspc <- screenWorkspace (W.screen sc) case maybeWkspc of Nothing -> return Nothing Just wkspc -> do let currentWksp = W.currentTag ws if currentWksp == wkspc then return Nothing else return (Just wkspc) ~~~~ - XMonad.Layout.BorderResize - XMonad.Layout.DecorationUtils Support for the BorderResize? - XMonad.Layout.DraggingVisualizer - XMonad.Layout.MouseResizableTile - XMonad.Layout.NoFrillsDecoration - XMonad.Layout.PositionStoreFloat - XMonad.Layout.ThreeColumnsMiddle just an alias for ThreeColumns - XMonad.Layout.WindowSwitcherDecoration looks like a module to use a mouse to 'drag' a window onto another and swap their positions # bluetile About what you would expect - importing most of the above, running the dock and the greeter. So to conclude this whirlwind tour: I see a lot of valuable stuff. The greeter is something that could definitely be in core (although I think the gtk2hs dep is untenable, so I expect a better idea would be to run an xmessage prompt with a list of keybindings). The dock is a nice alternative to the ridiculously baroque setups for xmobar and dzen - those may be really nice and customizable, but they are absolutely unsuitable for beginners, and even setting up a Gnome panel is a bit much for non-intermediate or advanced XMonaders. And the string atom stuff has already been done by Stumpwm/Ratpoison, and I asked for this in the past - XMonad should be scriptable from the outside. -- gwern

14 20

How to swap screen in a multihead environment?
by Felix Bou 04 Sep '09

04 Sep '09

I have just started to use xmonad, and it seems to me a great software for multihead screens. At his moment, I am using two physical screens and I would like to use a key binding to do the following thing: "swap screens". By swap screens I mean moving from -the configuration [1 2] to the configuration [2 1] -the configuration [1 3] to the configuration [3 1] -the configuration [4 2] to the configuration [2 4] etc When I say configuration [1 2] I mean that workspace 1 is on left screen and workspace2 in on right screen; and the same idea for [2 1], [1 3], etc Does anybody know how to do this?

4 3

Unmarking modules 'Unstable' in contrib
by Adam Vogt 03 Sep '09

03 Sep '09

Hello, Most (152/159) modules are marked as unstable in contrib. A good number of these 'unstable' modules have not been modified since a number of releases. Here's a rough total number of modules with a last-modified date (per year): > (for x in `find .`; do; (darcs changes $x | tail -n 2 | head -n 1); done) > lastmod > for x in {2007,2008,2009}; do; grep $x lastmod | wc -l; done 64 43 17 I wouldn't trust those numbers, since the total falls short of 159, but the point still stands: many so-called unstable modules have not changed in a long time, which could make it difficult for users to avoid modules that may actually change. Does anybody mind if I change the oldest modules (unchanged since 1.5 years) to be stable? -- Adam

2 2