- xmonad - Haskell.org

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 19 Jun '07

19 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 19 Jun '07

19 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

darcs patch: StackSet.hs: don't claim to be vanilla H... (and 1 more)
by joachim.fasting＠gmail.com 19 Jun '07

19 Jun '07

Tue Jun 19 01:31:25 CEST 2007 joachim.fasting(a)gmail.com * StackSet.hs: don't claim to be vanilla Haskell 98. Tue Jun 19 01:33:06 CEST 2007 joachim.fasting(a)gmail.com * StackSet.hs: add -fglasgow-exts.

2 1

Issue 25 in xmonad: Float fixed-size windows
by codesite-noreply＠google.com 18 Jun '07

18 Jun '07

Issue 25: Float fixed-size windows http://code.google.com/p/xmonad/issues/detail?id=25 Comment #3 by SpencerJanssen: I had trouble applying this patch (CRLF conversion problems), but I've applied an equivalent patch from the mailing list. Issue attribute updates: Status: Fixed -- 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 25 in xmonad: Float fixed-size windows
by codesite-noreply＠google.com 18 Jun '07

18 Jun '07

Issue 25: Float fixed-size windows http://code.google.com/p/xmonad/issues/detail?id=25 Comment #1 by SpencerJanssen: This seems to be the right thing to do. Specifically, we need to compare maximum and minimum widths and heights in WM_NORMAL_HINTS. If the maximum and minimum values are the same the window should float. I patiently await a patch :). Issue attribute updates: Status: Accepted Owner: SpencerJanssen Labels: Milestone-Release0.3 -- 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

3 2

Issue 25 in xmonad: Float fixed-size windows
by codesite-noreply＠google.com 18 Jun '07

18 Jun '07

Issue 25: Float fixed-size windows http://code.google.com/p/xmonad/issues/detail?id=25 Comment #2 by nornagon: Patch that fixes this attached. It's a bit ugly, but it works. I hope I patched right. Attachments: xmonad-float-fixed.patch 14.0 KB -- 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

darcs patch: Add an "accordion" layout which puts non-focused windo...
by glasser＠mit.edu 18 Jun '07

18 Jun '07

Mon Jun 18 11:39:43 EDT 2007 glasser(a)mit.edu * Add an "accordion" layout which puts non-focused windows in ribbons at the top and bottom of the screen.

4 5

darcs patch: MagicFocus.magicFocus: add type signature. (and 1 more)
by joachim.fasting＠gmail.com 18 Jun '07

18 Jun '07

Mon Jun 18 22:52:22 CEST 2007 joachim.fasting(a)gmail.com * MagicFocus.magicFocus: add type signature. Mon Jun 18 22:54:21 CEST 2007 joachim.fasting(a)gmail.com * MagicFocus.hs: add module header and usage instructions.

2 1