- xmonad - Haskell.org

StackSet patch
by Wouter Swierstra 04 May '09

04 May '09

I found a really minor bug in the "new" function in StackSet.hs. I've attached a patch to fix it. More interesting, however, is how I found this. I've been transcribing XMonad's StackSets to the functional language/proof assistant Coq. I've set up a darcs repository with my work so far: darcs get www.cs.nott.ac.uk/~wss/repos/StackSet At the moment I have a fairly complete implementation of StackSets in Coq. I have to admit that I did cut a few corners here and there, but there's nothing that can't be fixed with a bit more work. From this Coq file, you can (in principle) extract Haskell code that is pretty close to the current StackSet.hs. I should emphasize that I haven't proven much about StackSets just yet. This only shows that the definitions in StackSet.hs can be made total (i.e. non-crashing and terminating) in a richer type theory. It should be fun to prove some QuickCheck properties in Coq – which is what I'd like to do next. Wouter

2 1

darcs patch: Add lib to ghc searchpath with recompila... (and 1 more)
by Adam Vogt 04 May '09

04 May '09

Sat Mar 21 19:29:07 EDT 2009 Adam Vogt <vogt.adam(a)gmail.com> * Add lib to ghc searchpath with recompilation check Sun May 3 19:54:15 EDT 2009 Adam Vogt <vogt.adam(a)gmail.com> * Only watch mtime for .hs, .lhs, .hsc for ~/.xmonad/lib Previously xmonad would force a recompile due to the object files being too new, so only look at files which may contain haskell code.

1 0

Re: [xmonad] darcs patch: Config.hs, Operations.hs: +unfloat, unfloatFocused fun...
by Gwern Branwen 03 May '09

03 May '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Sat, May 2, 2009 at 3:54 PM, Don Stewart wrote: > They're in the default Config -- i.e. that binding is already in scope. > > So people are intentionally duplicating parts of the default config for > some reason. > > I think this is quite different to the case where there is a spontaneous > idiom appearing. > > -- Don You refer to just the ones duplicating the mod-t binding? I'd say it's an interesting example of how our keybinding system is suboptimal - even moderately competent users should not find themselves duplicating stuff like this. But anyway, even if you filter out the ones binding to xK_t, there're still 10 configs using this same function definition. Is that not enough? Before I invest anymore time in trying to make configs more concise & usable by factoring out commonalities, I'd appreciate some hard guidelines on when something is meritorious enough to be put in core and when it is not. - -- gwern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.5) iEYEAREKAAYFAkn9DpsACgkQvpDo5Pfl1oKF6gCeItWqEw6tOJZesV3ONrYWJmbB OcgAnjG98E+ZW1cwFmFUfjbfdjkNQRA3 =VybT -----END PGP SIGNATURE-----

2 1

darcs patch: U.Loggers: add maildirNew, other loggers, and logger f...
by Wirt Wolff 03 May '09

03 May '09

Sat Apr 11 22:13:56 MDT 2009 wirtwolff(a)gmail.com * U.Loggers: add maildirNew, other loggers, and logger formatting utilities Rework of the Logger portions of patches originally from seanmce33(a)gmail.com to apply without conflicts, plus several formatting utilities for use with X (Maybe String) aka Loggers.

3 2

patch: New XMonad.Layout.MessageControl module.
by Quentin Moser 03 May '09

03 May '09

Hi, These patches provide a message escape/filtering facility intended to make it easier to control complex nested layouts via messages. The first one provides "unEscape" and "ignore" modifiers you could use to write something like this: > import XMonad.Layout.MessageControl > > myLayout = Full ||| gimp ||| ... > where gimp = ignore NextLayout $ ignore JumpToLayout $ unEscape $ > mastered 0.01 0.2 (simpleTabbed ||| Grid) > > nextOuterLayout = sendMessage NextLayout > nextInnerLayout = sendMessage $ escape NextLayout (see the XMonad.Layout.MessageControl patch for details. For clarification, "ignore" blocks all messages of the _same type_ as its parameter.) However, neither XMonad.Layout.(|||) nor XMonad.Layout.LayoutCombinators.(|||) can be used with this, because they both send messages (NextLayoutNoWrap) which have a private type and therefore cannot be filtered. Thus the patch to X.L.LayoutCombinators, which moves the NoWrap messages from their own type into the JumpLayout type, so that they can now be intercepted with "ignore JumpToLayout". I also made these constructors public because I don't like exporting data types with only part of their constructors, but that's not actually necessary and can be reverted if wanted. ... Also, when adding these modifiers into my Big Monstrous LayoutHook of Hell I had to add an {-# OPTIONS_GHC -fcontext-stack=40 #-} pragma to my xmonad.hs to prevent a context reduction overflow =).

3 2

darcs patch: ThreeCol - Update docs to match reality
by Anders Engstrom 03 May '09

03 May '09

Sun May 3 21:07:55 CEST 2009 Anders Engstrom <ankaan(a)gmail.com> * ThreeCol - Update docs to match reality

2 1

darcs patch: nameTail - Remove the first word of a layout description
by Anders Engstrom 03 May '09

03 May '09

Sun May 3 12:59:50 CEST 2009 Anders Engstrom <ankaan(a)gmail.com> * nameTail - Remove the first word of a layout description

2 1

Turning emacs mini-buffer window into a strut
by John Yates 03 May '09

03 May '09

This is my first appearance in the xmonad community. Those tracking awesome may recognize this post as similar to one I posted earlier on that mailing list. Some backstory As a longtime C++ programmer I had assumed that awesome's imperative codebase (C++ and Lua) would present a gentler learning curve. I made some initial progress but ultimately found awesome still too immature and undocumented to give me confidence of achieving my various goals (of which possibly more in a subsequent posting). On switching to xmonad the greater maturity, generally good documentation, abundance of contributed modules and availablity of example configurations helped me greatly. The only thing I miss from awesome is its somewhat snappier performance. My guess would be that that has nothing to do with choice of implementation or scripting language, but rather with the fact that awesome is built on xcb while xmonad is built on classic xlib. My current challenge Years ago I loved Apollo workstations' DM (Display Manager). Ever since becoming an emacs user I have dreamed of recreating that environment. The emergence of robust tiling window managers and the example of Drew Adams' OneOnOne package (http://www.emacswiki.org/emacs/OneOnOneEmacs) leads me to believe that after a couple decades the dream may now be close to realization. For reference my environment is Ubuntu Jaunty, Gnome with a single top panel on a 1920x1200 screen. Under Gnome/Metacity I have emacs-snapshot (23.0.93.1) more or less working in the the single mini-buffer for all windows mode. (Here I use the term window to refer to what in the Emacs world would be called a frame.) The mini-buffer window is positioned at the bottom of the screen and is full-screen wide. Alternatively I can position the mini-buffer at the top of the screen just below the Gnome panel. Now I want to move this Emacs arrangement to xmonad. Because I have arranged for the mini-buffer window to have a distinct resource type I can recognize it in a manage hook. From the xmonad FAQ and some googling I believe that when that window appears I need to set its override-redirect attribute to true and define it as a strut. Though I am working my way through Hal Daumé's "Yet Another Haskell Tutorial" I fear it may be a while before I can code such a doStrut function. Thus my appeal to the readers of this list. My sense is that when the mini-buffer window appears it is properly sized and positioned. Thus there should be no need to compute the strut components, they should be directly liftable from the window. Thanks in advance for any help, /john

4 4

Window manager replacement (--replace flag)
by Jan Vornberger 03 May '09

03 May '09

Hi there! I have looked a little bit into enabling XMonad to replace an existing window manager when starting. I think it's a useful feature to help a new user to try out the window manager (e.g. from a running Gnome-Session with Metacity). I also found a corresponding 'issue' on the bug tracker (http://code.google.com/p/xmonad/issues/detail?id=99) which however has been closed as 'WontFix'. I have a rough version of the feature ready, which is good enough for my needs for now. It's not in a shape to go into the repository though, I'm only posting this here in case someone wants to continue working on it and for reference. The current version of the patch is attached. It's also available at my repository (http://tuvok.home.dyndns.org/xmonad-dev/xmonad/) I had a look at http://tronche.com/gui/x/icccm/sec-2.html#s-2.8 for reference, but mostly followed the code of other window managers. Namely XFWM4, Compiz and Metacity. If someone wants to look into it, here are the relevant parts: apt-get source xfwm4 -> edit screen.c -> search for myScreenSetWMAtom apt-get source compiz -> edit display.c -> search for replaceCurrentWm apt-get source metacity -> core/screen.c -> search for replace_current_wm My code does not everything these window managers do for this feature. The steps that I have skipped out of laziness and/or limited understanding of X11 programming, are marked with 'SKIPPED' in the code. Basically my code right now always replaces an existing window manager and assumes that everything goes fine. One other thing I noticed: While XMonad can now replace other window managers, it doesn't allow itself to be replaced in this manner. I haven't looked into it further, but we would need to play nice and terminate when we see another WM trying to take over. Things to do: - implement 'SKIPPED' parts - add '--replace' flag and only replace when the user specifies this flag - allow replacement of XMonad by another WM As I said, I have paused working on this feature for now. If anyone wants to have a shot at it, feel free to do so! :-) Cheers! Jan

1 0

darcs patch: Config.hs, Operations.hs: +unfloat, unfloatFocused fun...
by gwern0＠gmail.com 03 May '09

03 May '09

Sat May 2 14:26:31 EDT 2009 gwern0(a)gmail.com * Config.hs, Operations.hs: +unfloat, unfloatFocused functions 'unfloat' is the obvious inverse of the existing 'float' function, and so makes the API a little more rational. 'unfloatFocused' is easy once you have unfloat, and more importantly, is defined in >20 user configs; so obviously there's a need!

4 4