November 2009 - xmonad

Re: Issue 311 in xmonad: using noBorders on tabbed layout freezes tab bar on workspace change
by codesite-noreply＠google.com 12 Sep '10

12 Sep '10

Updates: Status: Accepted Labels: Type-Defect Component-Contrib Comment #5 on issue 311 by byorgey: using noBorders on tabbed layout freezes tab bar on workspace change http://code.google.com/p/xmonad/issues/detail?id=311 (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 2

Issue 336 in xmonad: xmonad won't start: Irrefutable pattern failed for pattern (Data.Maybe.Just nbc_)
by codesite-noreply＠google.com 26 Aug '10

26 Aug '10

Status: New Owner: ---- New issue 336 by flazzarino: xmonad won't start: Irrefutable pattern failed for pattern (Data.Maybe.Just nbc_) http://code.google.com/p/xmonad/issues/detail?id=336 What steps will reproduce the problem? 1. last line of ~/.xinitrc: exec /Users/franco/.cabal/bin/xmonad What is the expected output? What do you see instead? I expect to have xmonad launch but i get this error in console 11/13/09 2:36:51 PM org.x.startx[7572] xmonad-i386-darwin: XMonad/Main.hsc:(82,14)-(84,41): Irrefutable pattern failed for pattern (Data.Maybe.Just nbc_) What version of the product are you using? On what operating system? xmonad 0.9 (installed via cabal) ghc-version (6.10.4) installed via the package OSX 10.6.2 (Snow Leopard) Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". import XMonad main = xmonad defaultConfig #no output Please provide any additional information below. on a mailing list i've seen hints that X cannot support the colors gray and red but i'm using a very stock snow leopard X11, only fullscreen is turned on -- 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 333 in xmonad: mplayer doesn't go fullscreen
by codesite-noreply＠google.com 28 Jul '10

28 Jul '10

Status: New Owner: ---- New issue 333 by polux2001: mplayer doesn't go fullscreen http://code.google.com/p/xmonad/issues/detail?id=333 What steps will reproduce the problem? 1. install ubuntu 9.10 2. cabal install xmonad 3. mplayer somevideo 4. press F What is the expected output? What do you see instead? Nothing happens. This doesn't occur with other WM (metacity). Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". I'm using a customized xmonad.hs but the problem occurs with Config.hs found in he distribution. -- 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 13

Issue 347 in xmonad: Feature request: Adding new Topics as you go
by codesite-noreply＠google.com 21 May '10

21 May '10

Status: New Owner: ---- New issue 347 by quesel: Feature request: Adding new Topics as you go http://code.google.com/p/xmonad/issues/detail?id=347 Hi, it would be a nice feature if one would be able to add new topics on the fly. I have a static config containing lots of topics, but sometimes I have a task that requires a new topic and I dont want to add it to my config but just add it temporarily. Therefore, it would be nice, if there was a way to easily combine X.A.TopicSpaces with X.A.DynamicWorkspaces and X.Prompt. Something like a keybind that pops-up two prompts, one for the topic name and one for the action and then creates this new topic, and one for deleting topics... Best Regards, Jan -- 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 4

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

[jv@informatik.uni-bonn.de: xmonad entry for HCAR November 2009]
by Don Stewart 03 May '10

03 May '10

Can someone revise the HCAR entry? ----- Forwarded message from Janis Voigtländer <jv(a)informatik.uni-bonn.de> ----- Date: Mon, 16 Nov 2009 16:14:46 +0100 From: Janis Voigtländer <jv(a)informatik.uni-bonn.de> To: dons(a)cse.unsw.edu.au Subject: xmonad entry for HCAR November 2009 Dear Don, The xmonad entry for the Haskell Communities and Activities Report is already quite old. I had hoped for an updated entry for the upcoming edition. If you let me know, there is still a bit of time to produce a revision. For reference, below is the old entry. Best regards, Janis. \begin{hcarentry}{xmonad} \label{xmonad} \report{Don Stewart}%05/08 \status{active development} \makeheader xmonad is a tiling window manager for X. Windows are arranged automatically to tile the screen without gaps or overlap, maximizing screen use. Window manager features are accessible from the keyboard: a mouse is optional. xmonad is written, configured, and extensible in Haskell. 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. The new release 0.7 of xmonad added full support for the GNOME and KDE desktops, and adoption continues to grow, with binary packages of xmonad available for all major distributions. \FurtherReading \begin{compactitem} \item Homepage: \url{http://xmonad.org/} \item Darcs source: \texttt{darcs get} \url{http://code.haskell.org/xmonad} \item IRC channel: \verb+#xmonad @ irc.freenode.org+ \item Mailing list: \email{xmonad(a)haskell.org} \end{compactitem} \end{hcarentry} -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:jv@iai.uni-bonn.de ----- End forwarded message -----

4 6

darcs patch: Less refreshing / flickering in mouse-2 binding.
by Adam Vogt 03 May '10

03 May '10

Fri Oct 30 22:51:05 EDT 2009 Adam Vogt <vogt.adam(a)gmail.com> * Less refreshing / flickering in mouse-2 binding.

3 3

darcs patch: Clean .hi and .o files when recompiling
by Joachim Breitner 10 Apr '10

10 Apr '10

Hi, I’d like to see this in the next release, to reduce the delta between xmonad as shipped by debian and as it is on hackage: Wed Sep 9 10:15:57 CEST 2009 Joachim Breitner <mail(a)joachim-breitner.de> * Clean .hi and .o files when recompiling This patch is applied to the Debian packages since a few months. During the last ghc upgrade in Debian, people had to this manually to get their xmonad compilable again. This patch should mitigate this a bit. Greetings, Joachim

7 11

darcs patch: Pass extensible state via an environment variable when restarting
by Daniel Schoepe 06 Apr '10

06 Apr '10

Sat Nov 14 01:10:19 CET 2009 Daniel Schoepe <daniel.schoepe(a)gmail.com> * Pass extensible state via an environment variable when restarting This fixes a crash when an old xmonad binary would receive an additional state argument.

2 3

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