June 2007 - xmonad - Haskell.org

darcs patch: LayoutHooks.hs: add module header.
by joachim.fasting＠gmail.com 19 Jun '07

19 Jun '07

Tue Jun 19 22:45:04 CEST 2007 joachim.fasting(a)gmail.com * LayoutHooks.hs: add module header.

2 1

darcs patch: basic bindings to XGetWindowProperty
by Jason Creighton 19 Jun '07

19 Jun '07

Tue Jun 19 18:24:41 MDT 2007 Jason Creighton <jcreigh(a)gmail.com> * basic bindings to XGetWindowProperty getWindowProperty(8|16|32) can't do everything that XGetWindowProperty() can, but they should work fine for the case of simply getting a named property.

2 1

darcs patch: Fix XMonadContrib layouts to work with droundy's patch
by Shachaf Ben-Kiki 19 Jun '07

19 Jun '07

I know he said he was going to send one, but I needed my contrib modules to work, so I did it myself. Tue Jun 19 17:39:51 PDT 2007 Shachaf Ben-Kiki <shachaf(a)gmail.com> * Fix XMonadContrib layouts to work with droundy's patch Shachaf

1 1

darcs patch: Factor out pprWindowSet (and Xinerama version) from dynamicLog.
by Shachaf Ben-Kiki 19 Jun '07

19 Jun '07

Am I doing this correctly? I haven't sent patches with darcs before. Tue Jun 19 11:36:57 PDT 2007 Shachaf Ben-Kiki <shachaf(a)gmail.com> * Factor out pprWindowSet (and Xinerama version) from dynamicLog. This patch lets you pretty-print a WindowSet to a string, rather than always printing it out to stdout directly. Shachaf

2 1

darcs patch: make Layouts able to layout whatever they like.
by David Roundy 19 Jun '07

19 Jun '07

Hi all, This is a minor generification that allows Layouts to be used to lay out things other than windows. It makes no code change in core xmonad (just types gain an additional parameter), and obviously doesn't change the total number of lines. I think it's an improvement that will be useful, but I also haven't yet written any code to make use of it. Patch to XMonadContrib to follow. Most of the contrib layouts (and all the core ones) are generic. David Tue Jun 19 08:08:16 PDT 2007 David Roundy <droundy(a)darcs.net> * make Layouts able to layout whatever they like.

2 1

darcs patch: clean up TwoPane to work on Stacks as it ought.
by David Roundy 19 Jun '07

19 Jun '07

Hi all, Here's a cleanup of TwoPane to make it properly work with the new Stack input. It is now a pure Layout, which is much prettier. David Tue Jun 19 08:09:28 PDT 2007 David Roundy <droundy(a)darcs.net> * clean up TwoPane to work on Stacks as it ought.

1 0

darcs patch: run-xmonad.sh: don't hard-code path to mkfifo.
by joachim.fasting＠gmail.com 19 Jun '07

19 Jun '07

Tue Jun 19 14:42:12 CEST 2007 joachim.fasting(a)gmail.com * run-xmonad.sh: don't hard-code path to mkfifo. mkfifo isn't located in /sbin on all distributions (Gentoo puts it in /bin). By temporarily appending /sbin to PATH both setups are supported. 'which' and friends are not viable options since /sbin usually isn't in user's PATH by default.

1 0

[dzen] release 0.5.0
by Robert Manea 19 Jun '07

19 Jun '07

Hello, this release features * dynamic color support - change the foreground and/or background color of the input at runtime * keyboard support - bind actions to any keys * improved internal datastructures Get it here: http://gotmor.googlepages.com/dzen Bye, Rob. P.S.: If you are using dzen for any interesting task and would like to share your script be sure to send me a mail with a short description and the script in order to populate dzen's script archive (http://gotmor.googlepages.com/dzenscriptarchive)

2 4

eliminating Workspace?
by David Roundy 18 Jun '07

18 Jun '07

Hi all, I have an idea that I'd rather run by folks before implementing--particularly as my tag-as-not-Num patches haven't been accepted. I'd like to add a tag field to Stack data Stack i a = Stack { data :: !i -- name of this stack , focus :: !a -- focused thing in this set , up :: [a] -- clowns to the left , down :: [a] } -- jokers to the right deriving (Show, Read, Eq) and thus eliminate the Workspace data type. The goal of this would be to also eliminate the Screen and StackSet types, replacing them with something like: type Workspace i a = Either i (Stack i a) tag :: Workspace i a -> i tag (Left i) = i tag (Right s) = data s type Screen i a sid = Stack sid (Workspace i a) screen :: Screen i a sid -> sid screen = data workspace :: Screen i a sid -> Workspace i a workspace = focus . stack' type StackSet i a sid = Stack (M.Map a RationalRect) floating :: StackSet i a sid -> M.Map a RationalRect floating = data current :: StackSet i a sid -> Screen i a sid current = focus visible :: StackSet i a sid -> [Screen i a sid] visible s = reverse (up s) ++ down s hidden :: StackSet i a sid -> [Workspace i a] hidden s = map h (integrate s) where h scr = up scr ++ down scr As you can see, the idea would be to use type to define synonyms for the current data types, and functions to define accessors that grant the same information as the current data structures (with almost the same API). And indeed, Workspace, Screen and StackSet would still each be distinct types, so we aren't losing any typesafety. I think that code will be simplified: the same function can shift focus between Screens, Workspaces and Windows. We'll need a new function (easily written) to shift a Workspace to a given Screen, but on the whole things look to me like they'll be nicer. This data structure includes a bit more information than our current StackSet, in that it associates each Workspace with a given Screen. This was recently requested as an option, so I think this is a good thing. Note that this doesn't require a change of behavior, is just make the existing behavior slightly more complicated, and the behavior where Workspaces are pinned associated with screens possible. I only have one screen, but I can certainly imagine that if I had one large and one small screen, I might like to be able to designate certain Workspaces for either one or the other. As you can tell, this is part of my scheme to make xmonad code prettier. I greatly dislike having so many distinct data types, each implementing basically the same sort of functionality in different ways: * StackSet stores which Screen has focus... and which Workspaces aren't visible. * Screen stores which Workspace has focus on that screen, but has no information about unfocussed Workspaces (those are in StackSet). * Workspace stores which Window has focus, and also which other windows are on that Workspace. This is almost but not quite symmetric, and that bothers me. It also has the result that the order of Workspaces is not stored anywhere except in the workspace tags, which means we need to sort the workspaces in RotView. So we store focus-order (which is also enforced to be stacking order now) for Windows, but not for Workspaces or Screens. Which among other things means that there's no nice way for a user (or XMonadContrib module) to alter the focus order for either Screens or Workspaces. Anyhow, comments, suggestions and estimates as to whether such a drastic change would be accepted will all be appreciated. -- David Roundy http://www.darcs.net

2 2

darcs patch: Magnifier.hs: add usage instructions. (and 3 more)
by joachim.fasting＠gmail.com 18 Jun '07

18 Jun '07

Mon Jun 18 23:22:15 CEST 2007 joachim.fasting(a)gmail.com * Magnifier.hs: add usage instructions. Tue Jun 19 01:20:51 CEST 2007 joachim.fasting(a)gmail.com * Circle.hs: only compute sqrt 2 once. Tue Jun 19 01:47:03 CEST 2007 joachim.fasting(a)gmail.com * run-xmonad.sh: use $HOME when setting PATH. Tue Jun 19 02:28:49 CEST 2007 joachim.fasting(a)gmail.com * Anneal.hs: add module header.

2 1