From dons at cse.unsw.edu.au Tue May 1 03:50:42 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Tue May 1 03:48:05 2007 Subject: [Xmonad] How we wrote xmonad: part 1: StackSet + QuickCheck Message-ID: <20070501075042.GA25239@cse.unsw.EDU.AU> I've written a blog post on how the core of xmonad is implemented and QuickChecked. It might be useful for those seeking to understand the code: http://programming.reddit.com/info/1mcu8/comments -- Don From arcatan at kapsi.fi Tue May 1 04:32:24 2007 From: arcatan at kapsi.fi (Miikka Koskinen) Date: Tue May 1 04:29:46 2007 Subject: [Xmonad] patch: XMonadContrib.DwmPromote: dwm-like promote Message-ID: <20070501083224.GB15090@kapsi.fi> Hullo, I like the way dwm's equivalent to xmonad promote works, so I implemented dwmpromote. See the patch for details. -- Miikka Koskinen (also known as arcatan) -------------- next part -------------- New patches: [XMonadContrib.DwmPromote: dwm-like promote Miikka Koskinen **20070501082031 I like the way dwm's equivalent to xmonad's promote works, so I implemented dwmpromote. ] { addfile ./DwmPromote.hs hunk ./DwmPromote.hs 1 +----------------------------------------------------------------------------- +-- | +-- Module : XMonadContrib.DwmPromote +-- Copyright : (c) Miikka Koskinen 2007 +-- License : BSD3-style (see LICENSE) +-- +-- Maintainer : arcatan@kapsi.fi +-- +----------------------------------------------------------------------------- +-- +-- Dwm-like promote function for xmonad. +-- +-- Swaps focused window with the master window. If focus is in the +-- master, swap it with the next window in the stack. Focus stays in the +-- master. +-- +-- To use, modify your Config.hs to: +-- +-- import XMonadContrib.DwmPromote +-- +-- and add a keybinding or substitute promote with dwmpromote: +-- +-- , ((modMask, xK_Return), dwmpromote) +-- + +module XMonadContrib.DwmPromote (dwmpromote) where + +import XMonad +import Operations (windows) +import StackSet hiding (promote) +import qualified Data.Map as M + +dwmpromote :: X () +dwmpromote = windows promote + +promote :: (Integral i, Ord a) => StackSet i j a -> StackSet i j a +promote w = maybe w id $ do + a <- peek w -- fail if null + let stack = index (current w) w + let newstack = swap a (next stack a) stack + return $ w { stacks = M.insert (current w) newstack (stacks w), + focus = M.insert (current w) (head newstack) (focus w) } + where + next s a | head s /= a = head s -- focused is not master + | length s > 1 = s !! 1 + | otherwise = a } Context: [add simple date example Don Stewart **20070429064013] [more details Don Stewart **20070429061426] [add readme Don Stewart **20070429061329] [Initial import of xmonad contributions Don Stewart **20070429061150] Patch bundle hash: 283e5ea9923cb6acb59fb25a5416131fbf27d699 From pdewacht at gmail.com Tue May 1 06:36:14 2007 From: pdewacht at gmail.com (Peter De Wachter) Date: Tue May 1 06:33:51 2007 Subject: [Xmonad] [patch] size hints Message-ID: <87lkg8zv8h.wl%pdewacht@gmail.com> This patch makes xmonad obey (some) size hints set by clients, for example the aspect ratio hint set by mplayer. I also implemented the max size and size increment hints, as some clients seem to get confused if their window is "too large" (for example Xephyr). Problems with this patch: - The hints are retrieved every wm operation, which could hurt over a slow link. They should be cached (and xmonad should listen to property events) - The code is not integrated in the layout algorithm, which results in ugly gaps between windows. - Too many lines of code. -------------- next part -------------- A non-text attachment was scrubbed... Name: xmonad-sizehints.patch Type: application/octet-stream Size: 5560 bytes Desc: not available Url : http://www.haskell.org/pipermail/xmonad/attachments/20070501/dd4acfcb/xmonad-sizehints.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: X11-extras-bind-XGetWMNormalHints.patch Type: application/octet-stream Size: 4563 bytes Desc: not available Url : http://www.haskell.org/pipermail/xmonad/attachments/20070501/dd4acfcb/X11-extras-bind-XGetWMNormalHints.obj From pdewacht at gmail.com Tue May 1 19:05:53 2007 From: pdewacht at gmail.com (Peter De Wachter) Date: Tue May 1 19:03:19 2007 Subject: [Xmonad] [patch] size hints In-Reply-To: <87lkg8zv8h.wl%pdewacht@gmail.com> References: <87lkg8zv8h.wl%pdewacht@gmail.com> Message-ID: <87zm4okuum.wl%pdewacht@gmail.com> This version is cleaner. Still breaks the loc limit though. From pdewacht at gmail.com Tue May 1 19:07:17 2007 From: pdewacht at gmail.com (Peter De Wachter) Date: Tue May 1 19:04:44 2007 Subject: [Xmonad] [patch] size hints In-Reply-To: <87lkg8zv8h.wl%pdewacht@gmail.com> References: <87lkg8zv8h.wl%pdewacht@gmail.com> Message-ID: <87y7k8kusa.wl%pdewacht@gmail.com> Helps if I attach it... -------------- next part -------------- A non-text attachment was scrubbed... Name: xmonad-sizehints-v2.patch Type: application/octet-stream Size: 8229 bytes Desc: not available Url : http://www.haskell.org/pipermail/xmonad/attachments/20070502/9e8f11c9/xmonad-sizehints-v2-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: X11-extras-bind-XGetWMNormalHints-v2.patch Type: application/octet-stream Size: 5485 bytes Desc: not available Url : http://www.haskell.org/pipermail/xmonad/attachments/20070502/9e8f11c9/X11-extras-bind-XGetWMNormalHints-v2-0001.obj From alec at thened.net Tue May 1 19:19:18 2007 From: alec at thened.net (Alec Berryman) Date: Tue May 1 19:19:51 2007 Subject: [Xmonad] [patch] size hints In-Reply-To: <87lkg8zv8h.wl%pdewacht@gmail.com> References: <87lkg8zv8h.wl%pdewacht@gmail.com> Message-ID: <20070501231918.GA9614@thened.net> Peter De Wachter on 2007-05-01 12:36:14 +0200: > This patch makes xmonad obey (some) size hints set by clients, for > example the aspect ratio hint set by mplayer. I also implemented the > max size and size increment hints, as some clients seem to get > confused if their window is "too large" (for example Xephyr). I haven't tried your updated patch, but this version worked pretty well and is a nice usability improvement. I did some tests with zenity (GTK+ version of dialog) and was pleased to see that windows were of a sane size instead of stretched and distorted to full screen; pinentry-gtk for inputting GPG passphrases also acted nicely. Not all of the windows I expected to be resized were, though; in particular, the Konqueror/kwallet password prompt that is properly resized in dwm was still stretched to full screen. Additionally, the windows I tested that were resized appeared at the top-right of the screen instead of centered. I don't know if there's an optional hint to center them that zenity's not setting, if your code isn't acting on such a hint, or it's expected to be implemented in the window manager, but it would be nice if the windows appeared centered on the screen. From dons at cse.unsw.edu.au Wed May 2 01:02:07 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Wed May 2 00:59:29 2007 Subject: [Xmonad] [patch] size hints In-Reply-To: <20070501231918.GA9614@thened.net> References: <87lkg8zv8h.wl%pdewacht@gmail.com> <20070501231918.GA9614@thened.net> Message-ID: <20070502050207.GB28745@cse.unsw.EDU.AU> alec: > Peter De Wachter on 2007-05-01 12:36:14 +0200: > > > This patch makes xmonad obey (some) size hints set by clients, for > > example the aspect ratio hint set by mplayer. I also implemented the > > max size and size increment hints, as some clients seem to get > > confused if their window is "too large" (for example Xephyr). > > I haven't tried your updated patch, but this version worked pretty well > and is a nice usability improvement. Ok. That's good to know. > I did some tests with zenity (GTK+ version of dialog) and was pleased to > see that windows were of a sane size instead of stretched and distorted > to full screen; pinentry-gtk for inputting GPG passphrases also acted > nicely. Not all of the windows I expected to be resized were, though; > in particular, the Konqueror/kwallet password prompt that is properly > resized in dwm was still stretched to full screen. > > Additionally, the windows I tested that were resized appeared at the > top-right of the screen instead of centered. I don't know if there's an > optional hint to center them that zenity's not setting, if your code > isn't acting on such a hint, or it's expected to be implemented in the > window manager, but it would be nice if the windows appeared centered on > the screen. YEs. I think we'll probably take this patch as a starting point for an approach to handling hints. I quite like the 'no gaps' that are produced by the current layout system (which ignores all hints), but some applications seem to crucially expect certain geometry. If we can support hints, without resulting with ugly gapping of tiling, that would be best. -- Don From droundy at darcs.net Wed May 2 11:16:31 2007 From: droundy at darcs.net (David Roundy) Date: Wed May 2 11:13:49 2007 Subject: [Xmonad] darcs patch: add RotView module. Message-ID: Sat Apr 21 16:38:38 PDT 2007 David Roundy * add RotView module. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 1726 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/xmonad/attachments/20070502/c75996a7/attachment.bin From droundy at darcs.net Wed May 2 11:27:39 2007 From: droundy at darcs.net (David Roundy) Date: Wed May 2 11:24:59 2007 Subject: [Xmonad] extensible layouts? Message-ID: <20070502152738.GA28953@abridgegame.org> Hi all, I was wondering if there were any plans to add support for extensible layouts to xmonad? I haven't really gotten any comments on my patch to do so, and have no idea if the approach I sketched out is considered unacceptable, foolish, or what not. Or perhaps there's just no real interest in extensible layouts by the other developers? I'd rather not bother resolving the conflicts I've got with the recent burst of modifications if there's not much interest in the patch, particularly as my wrist has decided I shouldn't be using my computer very much--and I need to use one for work. -- David Roundy http://www.darcs.net From jcreigh at gmail.com Wed May 2 20:33:58 2007 From: jcreigh at gmail.com (Jason Creighton) Date: Wed May 2 20:31:23 2007 Subject: [Xmonad] darcs patch: run QC tests in addition to LOC test Message-ID: Wed May 2 18:32:02 MDT 2007 Jason Creighton * run QC tests in addition to LOC test -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 4600 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/xmonad/attachments/20070502/7a4303f2/attachment.bin From dons at cse.unsw.edu.au Wed May 2 20:48:36 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Wed May 2 20:45:54 2007 Subject: [Xmonad] extensible layouts? In-Reply-To: <20070502152738.GA28953@abridgegame.org> References: <20070502152738.GA28953@abridgegame.org> Message-ID: <20070503004836.GA30455@cse.unsw.EDU.AU> droundy: > Hi all, > > I was wondering if there were any plans to add support for extensible > layouts to xmonad? I haven't really gotten any comments on my patch to do > so, and have no idea if the approach I sketched out is considered > unacceptable, foolish, or what not. Or perhaps there's just no real > interest in extensible layouts by the other developers? On the contrary! We *really* want to support arbitrary user layouts specified in Config.hs (or elsewhere). I'd personally like ion-style tiling. We've spent a bit of time talking about this on #xmonad. The main issue is currently that the layout algos can't be specified from Config.hs, and we need/intend to resolve this before 0.2. > I'd rather not bother resolving the conflicts I've got with the recent > burst of modifications if there's not much interest in the patch, > particularly as my wrist has decided I shouldn't be using my computer very > much--and I need to use one for work. I think the best approach would be to work out a way to support user Config.hs, and then just have submitted algos go into XMonadContrib. Spencer, do you have some thoughts on this? -- Don From dons at cse.unsw.edu.au Wed May 2 21:41:18 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Wed May 2 21:38:36 2007 Subject: [Xmonad] Configurable tiling algos Message-ID: <20070503014117.GC30455@cse.unsw.EDU.AU> Regarding configurable tiling, a simple strategy would be to have user-specified tiling functions available from Config.hs, of the type tile :: Rational -> Rectangle -> [Window] -> [(Window, Rectangle)] type Tiler =Rational -> Rectangle -> [Window] -> [(Window, Rectangle)] so, myTile :: [Tiler] myTile = [someTileAlgo ,someOtherAlgo ] These functions are then added to the list of algos to cycle through in mod-space, and would allow custom pure functions. David, I suspect you actually want 'tile' to live in X, so you can do window name lookups and so on? Other than generalising the type a bit, how does this sound, as an approach to extending the tiling algo set with custom user-written methods. -- Don From droundy at darcs.net Wed May 2 21:43:08 2007 From: droundy at darcs.net (David Roundy) Date: Wed May 2 21:40:25 2007 Subject: [Xmonad] extensible layouts? In-Reply-To: <20070503004836.GA30455@cse.unsw.EDU.AU> References: <20070502152738.GA28953@abridgegame.org> <20070503004836.GA30455@cse.unsw.EDU.AU> Message-ID: <20070503014305.GA6343@abridgegame.org> On Thu, May 03, 2007 at 10:48:36AM +1000, Donald Bruce Stewart wrote: > droundy: > > I was wondering if there were any plans to add support for extensible > > layouts to xmonad? I haven't really gotten any comments on my patch to do > > so, and have no idea if the approach I sketched out is considered > > unacceptable, foolish, or what not. Or perhaps there's just no real > > interest in extensible layouts by the other developers? > > On the contrary! We *really* want to support arbitrary user layouts > specified in Config.hs (or elsewhere). I'd personally like ion-style > tiling. We've spent a bit of time talking about this on #xmonad. Have my patches to enable this been discussed at all? If there's interest, I could bring them back up to date with the recent changes, but I'd rather first hear that the general principle is acceptable. I think that storing the layout functions as functions which themselves hold whatever data they need in the functions themselves is quite elegant. And I suppose if we're willing to live with mutually recursive modules (which I personally despise), we could avoid the type-parametrization of the X monad that I introduced, by simply exporting the layout message type from Config into XMonad. > > I'd rather not bother resolving the conflicts I've got with the recent > > burst of modifications if there's not much interest in the patch, > > particularly as my wrist has decided I shouldn't be using my computer very > > much--and I need to use one for work. > > I think the best approach would be to work out a way to support user > Config.hs, and then just have submitted algos go into XMonadContrib. I absolutely agree. My XMonad repository was intended to function like this, only the interesting module (Mosaic) relies on the changes to allow extensible layout algorithms, which are now broken beyond the degree that I'm enthusiastic to fix them--without some sort of encouragement that this sort of approach is desirable. -- David Roundy Department of Physics Oregon State University From dons at cse.unsw.edu.au Wed May 2 21:47:31 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Wed May 2 21:44:49 2007 Subject: [Xmonad] extensible layouts? In-Reply-To: <20070503014305.GA6343@abridgegame.org> References: <20070502152738.GA28953@abridgegame.org> <20070503004836.GA30455@cse.unsw.EDU.AU> <20070503014305.GA6343@abridgegame.org> Message-ID: <20070503014730.GD30455@cse.unsw.EDU.AU> droundy: > On Thu, May 03, 2007 at 10:48:36AM +1000, Donald Bruce Stewart wrote: > > droundy: > > > I was wondering if there were any plans to add support for extensible > > > layouts to xmonad? I haven't really gotten any comments on my patch to do > > > so, and have no idea if the approach I sketched out is considered > > > unacceptable, foolish, or what not. Or perhaps there's just no real > > > interest in extensible layouts by the other developers? > > > > On the contrary! We *really* want to support arbitrary user layouts > > specified in Config.hs (or elsewhere). I'd personally like ion-style > > tiling. We've spent a bit of time talking about this on #xmonad. > > Have my patches to enable this been discussed at all? If there's interest, There were a few weeks ago, but the feeling then was that it was too much, too soon, in terms of complexity, while we were busy getting 0.1 done. The time has come to look at that again. > I could bring them back up to date with the recent changes, but I'd rather > first hear that the general principle is acceptable. I think that storing > the layout functions as functions which themselves hold whatever data they > need in the functions themselves is quite elegant. And I suppose if we're Yes. > willing to live with mutually recursive modules (which I personally > despise), we could avoid the type-parametrization of the X monad that I > introduced, by simply exporting the layout message type from Config into > XMonad. Which we already have (mutual recursion on Config.hs) > > > > I'd rather not bother resolving the conflicts I've got with the recent > > > burst of modifications if there's not much interest in the patch, > > > particularly as my wrist has decided I shouldn't be using my computer very > > > much--and I need to use one for work. > > > > I think the best approach would be to work out a way to support user > > Config.hs, and then just have submitted algos go into XMonadContrib. > > I absolutely agree. My XMonad repository was intended to function like > this, only the interesting module (Mosaic) relies on the changes to allow > extensible layout algorithms, which are now broken beyond the degree that > I'm enthusiastic to fix them--without some sort of encouragement that this > sort of approach is desirable. Right. Basically what we need is something simple and clean: since users are expected to write their own functions. But balancing this is the need to have enough flexibility to get at any values a user might want to utilise. I'll read through your original submission again. -- Don From dons at cse.unsw.edu.au Wed May 2 21:53:48 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Wed May 2 21:51:06 2007 Subject: [Xmonad] tshirts, yes, tshirts! Message-ID: <20070503015347.GE30455@cse.unsw.EDU.AU> Thanks to work by David Lazar, who also hosts xmonad.org for us, we now have rather nice xmonad tshirts! http://www.spreadshirt.com/shop.php?op=article&article_id=2125373#top and http://www.spreadshirt.com/shop.php?op=article&article_id=2124110#top :-) No one is making any money from these, other than the tshirt company, they're just for fun. -- Don From droundy at darcs.net Wed May 2 21:57:37 2007 From: droundy at darcs.net (David Roundy) Date: Wed May 2 21:54:54 2007 Subject: [Xmonad] Configurable tiling algos In-Reply-To: <20070503014117.GC30455@cse.unsw.EDU.AU> References: <20070503014117.GC30455@cse.unsw.EDU.AU> Message-ID: <20070503015737.GB6343@abridgegame.org> On Thu, May 03, 2007 at 11:41:18AM +1000, Donald Bruce Stewart wrote: > Regarding configurable tiling, a simple strategy would be to have > user-specified tiling functions available from Config.hs, of the type > > tile :: Rational -> Rectangle -> [Window] -> [(Window, Rectangle)] > type Tiler =Rational -> Rectangle -> [Window] -> [(Window, Rectangle)] > > so, > > myTile :: [Tiler] > myTile = [someTileAlgo > ,someOtherAlgo > ] > > These functions are then added to the list of algos to cycle through in > mod-space, and would allow custom pure functions. > > David, I suspect you actually want 'tile' to live in X, so you can do > window name lookups and so on? Possibly. I'd actually probably prefer passing in something like [(ExtraWindowInformation,Windowj)] instead of just [Window]. The downside would be that we'd have to get the ExtraWindowInformation (title, class, etc) whether we need it or not, but I suspect that wouldn't cause too much trouble. Or perhaps we'd want to define a new data type: data PureWindow = PureWindow { thewindow :: Window , thename :: String , ... } It's a little annoying (to me, anyhow) that the Eq instance of Window sometimes returns true between an old closed window and a newly opened window, so creating a new data type that doesn't have that issue might be handy. But my first and primary objection is that you've constrained all tiling algorithms to have at most one Rational of user-configurable data. To quote an early version of my extensible layout patch, I'd prefer something more like this as a starting point +data Layout = Layout { doLayout :: Rectangle -> [Window] -> [(Window, Rectangle)] + , modifyLayout :: String -> Maybe Layout } This allows each layout to have an arbitrary amount of user-configured data which can be configured at runtime. See my mosaic module for a layout in which the prefered size and aspect ratio of each window may be individually tailored (although I didn't implement arbitrary aspect ratios for each windows, it's either square or all the same configurable value). Then the available layouts are a [Layout] as in your case. The key is in the modifyLayout method, which allows you to pass new data to the layout (e.g. changing a window size or something). With mutual recursion (yuck), we'd probably want: data Layout = Layout { doLayout :: Rectangle -> [Window] -> [(Window, Rectangle)] , modifyLayout :: LayoutMessage -> Maybe Layout } where LayoutMessage is defined in Config. But I really hate mutual recursion. Not that I have much experience with it, since I never use it... -- David Roundy Department of Physics Oregon State University From timd at macquarie.com.au Wed May 2 22:00:44 2007 From: timd at macquarie.com.au (Tim Docker) Date: Wed May 2 21:58:09 2007 Subject: [Xmonad] tshirts, yes, tshirts! In-Reply-To: <20070503015347.GE30455@cse.unsw.EDU.AU> References: <20070503015347.GE30455@cse.unsw.EDU.AU> Message-ID: They _are_ cool... I like the graphics. Though I don't think I'd qualify to wear one until I was using xmonad beyond the tinkering stage... roll on extensible layouts! Tim -----Original Message----- From: xmonad-bounces@haskell.org [mailto:xmonad-bounces@haskell.org] On Behalf Of Donald Bruce Stewart Sent: Thursday, 3 May 2007 11:54 AM To: xmonad@haskell.org Subject: [Xmonad] tshirts, yes, tshirts! Thanks to work by David Lazar, who also hosts xmonad.org for us, we now have rather nice xmonad tshirts! http://www.spreadshirt.com/shop.php?op=article&article_id=2125373#top and http://www.spreadshirt.com/shop.php?op=article&article_id=2124110#top :-) No one is making any money from these, other than the tshirt company, they're just for fun. -- Don _______________________________________________ Xmonad mailing list Xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad From sjanssen at cse.unl.edu Wed May 2 22:03:31 2007 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Wed May 2 22:00:53 2007 Subject: [Xmonad] extensible layouts? In-Reply-To: <20070502152738.GA28953@abridgegame.org> References: <20070502152738.GA28953@abridgegame.org> Message-ID: <20070502210331.31562c0e@localhost> On Wed, 2 May 2007 08:27:39 -0700 David Roundy wrote: > Hi all, > > I was wondering if there were any plans to add support for extensible > layouts to xmonad? I haven't really gotten any comments on my patch > to do so, and have no idea if the approach I sketched out is > considered unacceptable, foolish, or what not. Or perhaps there's > just no real interest in extensible layouts by the other developers? I'm interested, but slow ;). Some comments about your patch: - I'd rather stay away from the parametricity on message type. Matching via Show is a bit ugly. I think a better representation is: > data Message = Shrink | Expand | Other Dynamic Layouts can then match against the core constructors, then fromDyn and match against special messages. - Should there be more messages? Specifically, messages like: WindowAdd, WindowRemove, InitializeLayout, UnitializeLayout. Otherwise, layouts that need to keep per-window state will need to compare their state against the window list on each 'refresh' call. - Can layouts do IO (or X ())? I've seen a handful of requests for ion style tabbing -- this requires IO to draw the tab bar. Additionally, the layout would need to listen to arbitrary X events to redraw the tab bar on ExposeNotify events. > I'd rather not bother resolving the conflicts I've got with the recent > burst of modifications if there's not much interest in the patch, > particularly as my wrist has decided I shouldn't be using my computer > very much--and I need to use one for work. I'm sorry about the lack of response until now. I put off looking closely at your patches, and "in a couple of hours" has turned into "a couple of weeks". Cheers, Spencer Janssen From sjanssen at cse.unl.edu Wed May 2 22:07:08 2007 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Wed May 2 22:04:32 2007 Subject: [Xmonad] darcs patch: add RotView module. In-Reply-To: References: Message-ID: <20070502210708.1ffa788d@localhost> On Wed, 02 May 2007 08:16:31 -0700 David Roundy wrote: > Sat Apr 21 16:38:38 PDT 2007 David Roundy > * add RotView module. Applied, thanks. A short comment describing the module would be nice, by the way. Cheers, Spencer Janssen From dons at cse.unsw.edu.au Wed May 2 22:30:00 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Wed May 2 22:27:17 2007 Subject: [Xmonad] What we're working on, and what's next Message-ID: <20070503023000.GG30455@cse.unsw.EDU.AU> Just to keep everyone informed about what is happening: * currently Spencer's working on the floating layer, some patches are landing, and we've discussed how to finish this. I'll probably start reviewing his patches by the weekend. * once the floating layer is stabilised, we'll turn to configurable layout. -- Don From codesite-noreply at google.com Wed May 2 23:04:39 2007 From: codesite-noreply at google.com (codesite-noreply@google.com) Date: Wed May 2 23:02:42 2007 Subject: [Xmonad] Issue 1 in project xmonad Message-ID: <163600cc53042f8818739fc9a8b98@google.com> Issue 1: Stable numlock handling. http://code.google.com/p/xmonad/issues/detail?id=1 Comment #2 by dons00: This is a test of the bug tracking system. Changes should be sent to xmonad@ -- 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 From codesite-noreply at google.com Wed May 2 23:25:40 2007 From: codesite-noreply at google.com (codesite-noreply@google.com) Date: Wed May 2 23:22:55 2007 Subject: [Xmonad] Issue 5 in project xmonad Message-ID: <163600cc53042f88639c5430a91e5@google.com> Issue 5: Not able to cycle through windows when in fullscreen layout mode http://code.google.com/p/xmonad/issues/detail?id=5 Comment #2 by SpencerJanssen: I've just pushed a patch related to keyboard layout changes that may fix your issue. Please try the latest X11-extras and xmonad from darcs. -- 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 From jcreigh at gmail.com Thu May 3 01:32:47 2007 From: jcreigh at gmail.com (Jason Creighton) Date: Thu May 3 01:30:05 2007 Subject: [Xmonad] darcs patch: comment: Gave URL to xinerama-enabled dmenu patch Message-ID: Wed May 2 23:31:33 MDT 2007 Jason Creighton * comment: Gave URL to xinerama-enabled dmenu patch -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 989 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/xmonad/attachments/20070502/305d228f/attachment.bin From chris at cmears.id.au Thu May 3 06:55:11 2007 From: chris at cmears.id.au (Chris Mears) Date: Thu May 3 06:54:05 2007 Subject: [Xmonad] Patch to make RotView work Message-ID: <87hcqu2n3k.fsf@loki.cmears.id.au> I had to apply the following patch to make the RotView contrib module build. -------------- next part -------------- A non-text attachment was scrubbed... Name: rotview-bundle Type: application/octet-stream Size: 1160 bytes Desc: not available Url : http://www.haskell.org/pipermail/xmonad/attachments/20070503/82379cdd/rotview-bundle-0001.obj From droundy at darcs.net Thu May 3 09:43:32 2007 From: droundy at darcs.net (David Roundy) Date: Thu May 3 09:40:48 2007 Subject: [Xmonad] Patch to make RotView work In-Reply-To: <87hcqu2n3k.fsf@loki.cmears.id.au> References: <87hcqu2n3k.fsf@loki.cmears.id.au> Message-ID: <20070503134332.GC29332@abridgegame.org> On Thu, May 03, 2007 at 08:55:11PM +1000, Chris Mears wrote: > I had to apply the following patch to make the RotView contrib module > build. Thanks! Obviously, I haven't gotten xmonad to build since my latest pull... -- David Roundy http://www.darcs.net From droundy at darcs.net Thu May 3 10:00:51 2007 From: droundy at darcs.net (David Roundy) Date: Thu May 3 09:58:07 2007 Subject: [Xmonad] extensible layouts? In-Reply-To: <20070502210331.31562c0e@localhost> References: <20070502152738.GA28953@abridgegame.org> <20070502210331.31562c0e@localhost> Message-ID: <20070503140050.GD29332@abridgegame.org> On Wed, May 02, 2007 at 09:03:31PM -0500, Spencer Janssen wrote: > On Wed, 2 May 2007 08:27:39 -0700 > David Roundy wrote: > > > Hi all, > > > > I was wondering if there were any plans to add support for extensible > > layouts to xmonad? I haven't really gotten any comments on my patch > > to do so, and have no idea if the approach I sketched out is > > considered unacceptable, foolish, or what not. Or perhaps there's > > just no real interest in extensible layouts by the other developers? > > I'm interested, but slow ;). > > Some comments about your patch: > > - I'd rather stay away from the parametricity on message type. > Matching via Show is a bit ugly. I think a better representation is: > > > data Message = Shrink | Expand | Other Dynamic > > Layouts can then match against the core constructors, then fromDyn and > match against special messages. We could certainly do this, but it seems rather ugly to me. Why should Shrink and Expand be special cases? Why not something more equitable, such as: type Message = Dynamic data StandardMessage = Shrink | Expand Then extension code wouldn't need *two* checks, first to see if the Message is Other, and then to use fromDynamic to see if it's a recognized message. > - Should there be more messages? Specifically, messages like: > WindowAdd, WindowRemove, InitializeLayout, UnitializeLayout. > Otherwise, layouts that need to keep per-window state will need to > compare their state against the window list on each 'refresh' call. I'd say we may as well wait until there's a use for these before adding the interface. Comparing state versus the window list costs a very little amount of processor time (and very little code), while API complexity is relatively expensive in terms of developer time (we'd need to always keep things in sync). > - Can layouts do IO (or X ())? I've seen a handful of requests for > ion style tabbing -- this requires IO to draw the tab bar. > Additionally, the layout would need to listen to arbitrary X events to > redraw the tab bar on ExposeNotify events. I'd say they'll definitely need to learn to do this, but that it should be in a second refactor. I don't think the design need be very different, and we definitely want to support pure functional layouts as well. -- David Roundy http://www.darcs.net From droundy at darcs.net Thu May 3 10:45:37 2007 From: droundy at darcs.net (David Roundy) Date: Thu May 3 10:42:52 2007 Subject: [Xmonad] darcs patch: include all source code in LOC count. Message-ID: This patch has us include the hs-boot file as source code, which only seems fair. After all, it's yet another bit of code that needs to be kept in sync with the rest. David Thu May 3 07:05:51 PDT 2007 David Roundy * include all source code in LOC count. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 5125 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/xmonad/attachments/20070503/fe85abad/attachment.bin From droundy at darcs.net Thu May 3 10:49:43 2007 From: droundy at darcs.net (David Roundy) Date: Thu May 3 10:46:57 2007 Subject: [Xmonad] darcs patch: add support for extensible layouts. Message-ID: Hi all, Here's a rework of my extensible layouts patch. It doesn't add any new features, instead it's just a minimal refactoring to allow extensible layouts. David Thu May 3 07:47:50 PDT 2007 David Roundy * add support for extensible layouts. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 11979 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/xmonad/attachments/20070503/727531f8/attachment.bin From droundy at darcs.net Thu May 3 11:17:11 2007 From: droundy at darcs.net (David Roundy) Date: Thu May 3 11:14:26 2007 Subject: [Xmonad] darcs patch: add Mosaic layout. Message-ID: Hi all, This adds my Mosaic extensible layout, using the extensible layouts patch that I just sent in. This isn't a terribly sophisticated layout engine, but at least it works better for me than any of the default ones. And more to the point, it demonstrates how to use the extensible layout patch that I just sent in to implement a non-trivial layout scheme. If you want to play with this, the interesting bindings are: mod-L : make windows wider mod-H : make windows taller mod-shift-L : Make currently focussed window bigger mod-shift-H : Make currently focussed window smaller mod-shift-S : Try to make the currently focussed window square, if possible All these adjustments are remembered, so you can arrange things as you wish, to a limited extent. As I said, it's pretty crude. An obvious extension would be to use windowing hints (e.g. from the recently posted patch) to get better defaults for the preferred aspect ratios and sizes. The layout algorithm isn't smart enough currently to even handle absolute sizes for windows. But that's the sort of thing that'd be worth adding. David Thu May 3 08:10:24 PDT 2007 David Roundy * add Mosaic layout. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 8997 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/xmonad/attachments/20070503/0da7ce47/attachment-0001.bin From sjanssen at cse.unl.edu Thu May 3 16:16:18 2007 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Thu May 3 16:16:16 2007 Subject: [Xmonad] darcs patch: comment: Gave URL to xinerama-enabled dmenu patch In-Reply-To: References: Message-ID: <20070503151618.45a96ce0@localhost> On Wed, 02 May 2007 23:32:47 -0600 Jason Creighton wrote: > Wed May 2 23:31:33 MDT 2007 Jason Creighton > * comment: Gave URL to xinerama-enabled dmenu patch Applied. From sjanssen at cse.unl.edu Thu May 3 16:17:23 2007 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Thu May 3 16:17:14 2007 Subject: [Xmonad] Patch to make RotView work In-Reply-To: <87hcqu2n3k.fsf@loki.cmears.id.au> References: <87hcqu2n3k.fsf@loki.cmears.id.au> Message-ID: <20070503151723.43bdaca6@localhost> On Thu, 03 May 2007 20:55:11 +1000 Chris Mears wrote: > I had to apply the following patch to make the RotView contrib module > build. > Applied. From sjanssen at cse.unl.edu Thu May 3 16:28:06 2007 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Thu May 3 16:28:05 2007 Subject: [Xmonad] darcs patch: include all source code in LOC count. In-Reply-To: References: Message-ID: <20070503152806.5316c346@localhost> On Thu, 03 May 2007 07:45:37 -0700 David Roundy wrote: > This patch has us include the hs-boot file as source code, which only > seems fair. After all, it's yet another bit of code that needs to be > kept in sync with the rest. I'm not sure that I agree with this sentiment. I'd consider hs-boot a part of the build system, to get around GHC's mishandling of module cycles. Anyone else have an opinion? Cheers, Spencer Janssen From sjanssen at cse.unl.edu Thu May 3 17:53:29 2007 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Thu May 3 17:53:17 2007 Subject: [Xmonad] darcs patch: add support for extensible layouts. In-Reply-To: References: Message-ID: <20070503165329.147c4aa5@localhost> On Thu, 03 May 2007 07:49:43 -0700 David Roundy wrote: > Hi all, > > Here's a rework of my extensible layouts patch. It doesn't add any > new features, instead it's just a minimal refactoring to allow > extensible layouts. > > David > > Thu May 3 07:47:50 PDT 2007 David Roundy > * add support for extensible layouts. > Thanks, I've applied this patch. I think there is room for improvement, but at least this patch gets the ball rolling. Cheers, Spencer Janssen From sjanssen at cse.unl.edu Thu May 3 17:55:00 2007 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Thu May 3 17:54:52 2007 Subject: [Xmonad] darcs patch: add Mosaic layout. In-Reply-To: References: Message-ID: <20070503165500.403b4044@localhost> On Thu, 03 May 2007 08:17:11 -0700 David Roundy wrote: > Thu May 3 08:10:24 PDT 2007 David Roundy > * add Mosaic layout. > Applied, thanks. Spencer Janssen From chris at cmears.id.au Thu May 3 18:24:23 2007 From: chris at cmears.id.au (Chris Mears) Date: Thu May 3 18:23:16 2007 Subject: [Xmonad] darcs patch: Fix instructions in Mosaic. Message-ID: Fri May 4 08:23:45 EST 2007 Chris Mears * Fix instructions in Mosaic. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 1411 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/xmonad/attachments/20070504/825018ce/attachment.bin From sjanssen at cse.unl.edu Thu May 3 19:20:47 2007 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Thu May 3 19:18:08 2007 Subject: [Xmonad] darcs patch: Fix instructions in Mosaic. In-Reply-To: References: Message-ID: <20070503182047.2c6f5b8d@localhost> On Fri, 04 May 2007 08:24:23 +1000 Chris Mears wrote: > Fri May 4 08:23:45 EST 2007 Chris Mears > * Fix instructions in Mosaic. Applied, thanks. Spencer Janssen From dons at cse.unsw.edu.au Thu May 3 19:51:06 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Thu May 3 19:48:22 2007 Subject: [Xmonad] darcs patch: include all source code in LOC count. In-Reply-To: <20070503152806.5316c346@localhost> References: <20070503152806.5316c346@localhost> Message-ID: <20070503235106.GA31275@cse.unsw.EDU.AU> sjanssen: > On Thu, 03 May 2007 07:45:37 -0700 > David Roundy wrote: > > > This patch has us include the hs-boot file as source code, which only > > seems fair. After all, it's yet another bit of code that needs to be > > kept in sync with the rest. > > I'm not sure that I agree with this sentiment. I'd consider hs-boot a > part of the build system, to get around GHC's mishandling of module > cycles. > > Anyone else have an opinion? .hs-boot doesn't count, imo. From jcreigh at gmail.com Thu May 3 20:44:51 2007 From: jcreigh at gmail.com (Jason Creighton) Date: Thu May 3 20:42:06 2007 Subject: [Xmonad] darcs patch: include all source code in LOC count. In-Reply-To: <20070503152806.5316c346@localhost> References: <20070503152806.5316c346@localhost> Message-ID: <20070504004450.GA20064@jpc.example.com> On Thu, May 03, 2007 at 03:28:06PM -0500, Spencer Janssen wrote: > On Thu, 03 May 2007 07:45:37 -0700 > David Roundy wrote: > > > This patch has us include the hs-boot file as source code, which only > > seems fair. After all, it's yet another bit of code that needs to be > > kept in sync with the rest. > > I'm not sure that I agree with this sentiment. I'd consider hs-boot a > part of the build system, to get around GHC's mishandling of module > cycles. > > Anyone else have an opinion? I think the whole LOC counting thing is somewhat silly to begin with and I would prefer to abandon the whole idea of keeping xmonad under some arbitrary number of lines. This is probably a sign of personal laziness, but I find the LOC limit has a "chilling effect" on certain types of refactorings. ("hmm...this line is getting kinda long...I should probably break that out over a couple lines...but that will increase the LOC count...") I'm sure if I was a cool uber-hacker, I'd go ahead and break it out over a couple lines, and then make up the lines somewhere else in some other clever, clean refactoring. But I'm not, and in my case, at least, laziness seems to win out. Of course, the other side of that coin is encouraging refactors that reduce LOC legitimately. ISTR whining to dons about the pointlessness of counting LOC earlier, and he said that the LOC limit in dwm had helped create a culture of refactoring in that community. Would you mind expanding upon that a little bit, Don? WRT the actual issue at hand, I don't know. It's somewhat like having to have a .h file in C. They *should* be auto-generated, but they aren't. Does dwm count .h files? Jason Creighton From dons at cse.unsw.edu.au Thu May 3 20:48:34 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Thu May 3 20:45:49 2007 Subject: [Xmonad] darcs patch: include all source code in LOC count. In-Reply-To: <20070504004450.GA20064@jpc.example.com> References: <20070503152806.5316c346@localhost> <20070504004450.GA20064@jpc.example.com> Message-ID: <20070504004834.GB31335@cse.unsw.EDU.AU> jcreigh: > On Thu, May 03, 2007 at 03:28:06PM -0500, Spencer Janssen wrote: > > On Thu, 03 May 2007 07:45:37 -0700 > > David Roundy wrote: > > > > > This patch has us include the hs-boot file as source code, which only > > > seems fair. After all, it's yet another bit of code that needs to be > > > kept in sync with the rest. > > > > I'm not sure that I agree with this sentiment. I'd consider hs-boot a > > part of the build system, to get around GHC's mishandling of module > > cycles. > > > > Anyone else have an opinion? > > I think the whole LOC counting thing is somewhat silly to begin with and > I would prefer to abandon the whole idea of keeping xmonad under some > arbitrary number of lines. This is probably a sign of personal laziness, > but I find the LOC limit has a "chilling effect" on certain types of > refactorings. ("hmm...this line is getting kinda long...I should > probably break that out over a couple lines...but that will increase the > LOC count...") I'm sure if I was a cool uber-hacker, I'd go ahead and > break it out over a couple lines, and then make up the lines somewhere > else in some other clever, clean refactoring. But I'm not, and in my > case, at least, laziness seems to win out. > > Of course, the other side of that coin is encouraging refactors that > reduce LOC legitimately. ISTR whining to dons about the pointlessness of > counting LOC earlier, and he said that the LOC limit in dwm had helped > create a culture of refactoring in that community. Would you mind > expanding upon that a little bit, Don? I think its an interesting exercise, and there's no reason to abandon it just yet. The loc limit encourages precision, getting the exact patch we want. As with dwm, but even moreso, it is encouraging a culture of refactoring. And that's a good thing for a window manager that is supposed to be a precision machine, built up from pure components and QuickCheck properties :-) -- Don From droundy at darcs.net Thu May 3 21:33:29 2007 From: droundy at darcs.net (David Roundy) Date: Thu May 3 21:30:46 2007 Subject: [Xmonad] darcs patch: add support for extensible layouts. In-Reply-To: <20070503165329.147c4aa5@localhost> References: <20070503165329.147c4aa5@localhost> Message-ID: <20070504013328.GA31245@abridgegame.org> On Thu, May 03, 2007 at 04:53:29PM -0500, Spencer Janssen wrote: > Thanks, I've applied this patch. I think there is room for improvement, > but at least this patch gets the ball rolling. Great! And I definitely agree about the quantity of room for improvement. -- David Roundy http://www.darcs.net From jcreigh at gmail.com Thu May 3 21:49:35 2007 From: jcreigh at gmail.com (Jason Creighton) Date: Thu May 3 21:46:53 2007 Subject: [Xmonad] darcs patch: added mirrorLayout to mirror arbitrary layouts Message-ID: Thu May 3 19:46:53 MDT 2007 Jason Creighton * added mirrorLayout to mirror arbitrary layouts -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 7194 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/xmonad/attachments/20070503/245d86e9/attachment-0001.bin From jcreigh at gmail.com Thu May 3 21:52:07 2007 From: jcreigh at gmail.com (Jason Creighton) Date: Thu May 3 21:49:26 2007 Subject: [Xmonad] darcs patch: use anyKey constant instead of magic number Message-ID: Thu May 3 19:50:43 MDT 2007 Jason Creighton * use anyKey constant instead of magic number -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 5708 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/xmonad/attachments/20070503/610e22bb/attachment.bin From dons at cse.unsw.edu.au Thu May 3 23:01:51 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Thu May 3 22:59:06 2007 Subject: [Xmonad] Configurable tiling algos In-Reply-To: <20070503015737.GB6343@abridgegame.org> References: <20070503014117.GC30455@cse.unsw.EDU.AU> <20070503015737.GB6343@abridgegame.org> Message-ID: <20070504030151.GE31335@cse.unsw.EDU.AU> droundy: > On Thu, May 03, 2007 at 11:41:18AM +1000, Donald Bruce Stewart wrote: > > Regarding configurable tiling, a simple strategy would be to have > > user-specified tiling functions available from Config.hs, of the type > > > > tile :: Rational -> Rectangle -> [Window] -> [(Window, Rectangle)] > > type Tiler =Rational -> Rectangle -> [Window] -> [(Window, Rectangle)] > > > > so, > > > > myTile :: [Tiler] > > myTile = [someTileAlgo > > ,someOtherAlgo > > ] > > > > These functions are then added to the list of algos to cycle through in > > mod-space, and would allow custom pure functions. > > > > David, I suspect you actually want 'tile' to live in X, so you can do > > window name lookups and so on? > > Possibly. I'd actually probably prefer passing in something like > [(ExtraWindowInformation,Windowj)] instead of just [Window]. The downside > would be that we'd have to get the ExtraWindowInformation (title, class, > etc) whether we need it or not, but I suspect that wouldn't cause too much > trouble. Or perhaps we'd want to define a new data type: > > data PureWindow = PureWindow { thewindow :: Window > , thename :: String > , ... } > > It's a little annoying (to me, anyhow) that the Eq instance of Window > sometimes returns true between an old closed window and a newly opened > window, so creating a new data type that doesn't have that issue might be > handy. > > But my first and primary objection is that you've constrained all tiling > algorithms to have at most one Rational of user-configurable data. To > quote an early version of my extensible layout patch, I'd prefer something > more like this as a starting point > > +data Layout = Layout { doLayout :: Rectangle -> [Window] -> [(Window, Rectangle)] > + , modifyLayout :: String -> Maybe Layout } > > This allows each layout to have an arbitrary amount of user-configured data > which can be configured at runtime. See my mosaic module for a layout in > which the prefered size and aspect ratio of each window may be individually > tailored (although I didn't implement arbitrary aspect ratios for each > windows, it's either square or all the same configurable value). > > Then the available layouts are a [Layout] as in your case. > > The key is in the modifyLayout method, which allows you to pass new data to > the layout (e.g. changing a window size or something). > > > > With mutual recursion (yuck), we'd probably want: > > data Layout = Layout { doLayout :: Rectangle -> [Window] -> [(Window, Rectangle)] > , modifyLayout :: LayoutMessage -> Maybe Layout } > > where LayoutMessage is defined in Config. But I really hate mutual > recursion. Not that I have much experience with it, since I never use > it... Regarding this last point, I find the use of Dynamic (let alone String) a bit irksome in the current code. We have all the possible layout messages known statically, since we statically compile and link Config.hs. So we should be able to take advantage of that, and have message handling code checked. So yes, given we already have mutual recursion on Config.hs, exporting the data type from Config.hs, with the upside that we delay no type checking to runtime of message forms, seems like a win to me. -- Don From dons at cse.unsw.edu.au Fri May 4 00:08:42 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Fri May 4 00:05:57 2007 Subject: [Xmonad] statically checked non-empty layout lists Message-ID: <20070504040841.GF31335@cse.unsw.EDU.AU> The new layout code introduces more chances for runtime errors than I'd like. In particular, the Dynamic type, and the possibility of users defining empty layout lists. Here's a cute approach, purely for instructive purposes, on statically checked non empty layout lists for Config.hs: Given a GADT for non-empty lists: data Empty data NonEmpty data List x y where Nil :: List Empty x Cons :: x -> List y x -> List NonEmpty x toList :: List t a -> [a] toList Nil = [] toList (Cons x y) = x : toList y infixr 5 .:. (.:.) :: x -> List t x -> List NonEmpty x (.:.) = Cons We can constrain: defaultLayouts :: List NonEmpty Layout meaning that this becomes a statically checked error: defaultLayouts = Nil resulting in: Config.hs:138:17: Couldn't match expected type `NonEmpty' against inferred type `Empty' Expected type: List NonEmpty Layout Inferred type: List Empty Layout While this is fine: defaultLayouts :: List NonEmpty Layout defaultLayouts = full .:. tall defaultDelta (1%2) .:. Nil Cute huh? -- Don From dons at cse.unsw.edu.au Fri May 4 00:16:35 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Fri May 4 00:13:51 2007 Subject: [Xmonad] statically checked non-empty layout lists In-Reply-To: <20070504040841.GF31335@cse.unsw.EDU.AU> References: <20070504040841.GF31335@cse.unsw.EDU.AU> Message-ID: <20070504041635.GG31335@cse.unsw.EDU.AU> dons: > The new layout code introduces more chances for runtime errors than I'd > like. In particular, the Dynamic type, and the possibility of users > defining empty layout lists. And a patch, just so its archived somewhere. New patches: [Use a GADT for non-empty list checking Don Stewart **20070504041020] { hunk ./Config.hs 137 -defaultLayouts :: [Layout] -defaultLayouts = [ full, tall defaultDelta (1%2), wide defaultDelta (1%2) ] +defaultLayouts :: List NonEmpty Layout +defaultLayouts = full .:. tall defaultDelta (1%2) .:. wide defaultDelta (1%2) .:. Nil hunk ./Config.hs-boot 2 -import XMonad (Layout) +import XMonad (Layout,List,NonEmpty) hunk ./Config.hs-boot 4 -defaultLayouts :: [Layout] +defaultLayouts :: List NonEmpty Layout hunk ./Main.hs 58 - , focusedBorder = fbc - } + , focusedBorder = fbc } hunk ./Main.hs 61 - , layouts = M.empty - } + , layouts = M.empty } hunk ./Operations.hs 51 + hunk ./Operations.hs 53 + hunk ./Operations.hs 148 - fl = M.findWithDefault defaultLayouts n $ layouts s + fl = M.findWithDefault (toList defaultLayouts) n $ layouts s hunk ./XMonad.hs 20 - runX, io, withDisplay, isRoot, spawn, trace, whenJust + runX, io, withDisplay, isRoot, spawn, trace, whenJust, + toList, List(..), NonEmpty, (.:.) hunk ./XMonad.hs 103 +data Empty +data NonEmpty + +data List x y where + Nil :: List Empty x + Cons :: x -> List y x -> List NonEmpty x + +toList :: List t a -> [a] +toList Nil = [] +toList (Cons x y) = x : toList y + +infixr 5 .:. +(.:.) :: x -> List t x -> List NonEmpty x +(.:.) = Cons + } Context: [refactoring, style, comments on new layout code Don Stewart **20070504023618] [use anyKey constant instead of magic number Jason Creighton **20070504015043] [added mirrorLayout to mirror arbitrary layouts Jason Creighton **20070504014653] [Fix layout switching order Spencer Janssen **20070503235632] [More Config.hs bugs Spencer Janssen **20070503234607] [Revert accidental change to Config.hs Spencer Janssen **20070503233148] [Add -fglasgow-exts for pattern guards. Properties.hs doesn't complain anymore Spencer Janssen **20070503214221] [Avoid the unsafe pattern match, in case Config.hs has no layouts Spencer Janssen **20070503214007] [add support for extensible layouts. David Roundy **20070503144750] [comments. and stop tracing events to stderr Don Stewart **20070503075821] [-Wall police Don Stewart **20070503074937] [elaborate documentation in Config.hs Don Stewart **20070503074843] [Use updated refreshKeyboardMapping. Requires latest X11-extras Spencer Janssen **20070503032040] [run QC tests in addition to LOC test Jason Creighton **20070503003202] [Add 'mod-n': refreshes current layout Spencer Janssen **20070503002252] [Fix tests after StackSet changes Spencer Janssen **20070502201622] [First steps to adding floating layer Spencer Janssen **20070502195917] [update motivational text using xmonad.org Don Stewart **20070502061859] [Sort dependencies in installation order Spencer Janssen **20070501204249] [Recommend X11-extras 0.1 Spencer Janssen **20070501204121] [elaborate description in .cabal Don Stewart **20070501035414] [use -fasm by default. Much faster Don Stewart **20070501031220] [Make border width configurable Spencer Janssen **20070430163515] [Add Config.hs-boot, remove defaultLayoutDesc from XConf Spencer Janssen **20070430162647] [Comment only Spencer Janssen **20070430161635] [Comment only Spencer Janssen **20070430161511] [check we never generate invalid stack sets Don Stewart **20070430065946] [view n . shift n . view i . shift i) x == x --> shift + view is invertible Don Stewart **20070430062901] [add rotate all and view idempotency tests Don Stewart **20070430055751] [Add XConf for values that don't change. Spencer Janssen **20070430054715] [Control.Arrow is suspicious, add an explicit import Spencer Janssen **20070430053623] [push is idempotent Don Stewart **20070430054345] [add two properties relating to empty window managers Don Stewart **20070430051016] [configurable border colors Jason Creighton **20070430043859 This also fixes a bug where xmonad was assuming a 24-bit display, and just using, eg, 0xff0000 as an index into a colormap without querying the X server to determine the proper pixel value for "red". ] [new QC property: opening a window only affects the current screen Don Stewart **20070430050133] [a bit more precise about building non-empty stacksets for one test Don Stewart **20070430035729] [remove redundant call to 'delete' in 'shift' Don Stewart **20070430031151] [clean 'delete' a little Don Stewart **20070430025319] [shrink 'swap' Don Stewart **20070430024813] [shrink 'rotate' a little Don Stewart **20070430024525] [move size into Properties.hs Don Stewart **20070430021758] [don't need 'size' operation on StackSet Don Stewart **20070430015927] [avoid grabbing all keys when a keysym is undefined Jason Creighton **20070428180046 XKeysymToKeycode() returns zero if the keysym is undefined. Zero also happens to be the value of AnyKey. ] [add homepage: field to .cabal file Don Stewart **20070429041011] [add fromList to Properties.hs Don Stewart **20070429035823] [move fromList into Properties.hs, -17 loc Don Stewart **20070429035804] [Further refactoring Spencer Janssen **20070426212257] [Refactor in Config.hs (no real changes) Spencer Janssen **20070426211407] [Add the manpage to extra-source-files Spencer Janssen **20070426014105] [add xmonad manpage David Lazar **20070426010812] [Remove toList Spencer Janssen **20070426005713] [Ignore numlock and capslock in keybindings Jason Creighton **20070424013357] [Clear numlock bit Spencer Janssen **20070424010352] [force window border to 1px Jason Creighton **20070423050824] [s/creigh// Don Stewart **20070423024026] [some other things to do Don Stewart **20070423023151] [Start TODOs for 0.2 Spencer Janssen **20070423021526] [update readme Don Stewart **20070422090507] [TAG 0.1 Spencer Janssen **20070422083033] Patch bundle hash: 5e766922308da95a360e50a2a978e76215434b6e From dons at cse.unsw.edu.au Fri May 4 04:03:05 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Fri May 4 04:00:18 2007 Subject: [Xmonad] Constrained dynamically extensible layout events: a patch Message-ID: <20070504080304.GC302@cse.unsw.EDU.AU> David, Spencer et al, are there any problems with restricting layoutMsg arguments to being members of the (open) Message class? I'd (strongly) prefer this over just Dynamic, since it restores most of the static checking we'd need. The only change for something like Mosaic would be to add the mosaic events to Message, with instance Message MyType, and to switch layoutMsg to sendMessage (its our 'throw' for dynamically extensible messages, in fact). The idea of constrained extensible messages is from SimonM's 06 HW paper on extensible exceptions. Comments? -- Don New patches: [Constrain layout messages to be members of a Message class Don Stewart **20070504075233 Using Typeables as the only constraint on layout messages is a bit scary, as a user can send arbitrary values to layoutMsg, whether they make sense or not: there's basically no type feedback on the values you supply to layoutMsg. Folloing Simon Marlow's dynamically extensible exceptions paper, we use an existential type, and a Message type class, to constrain valid arguments to layoutMsg to be valid members of Message. That is, a user writes some data type for messages their layout algorithm accepts: data MyLayoutEvent = Zoom | Explode | Flaming3DGlassEffect deriving (Typeable) and they then add this to the set of valid message types: instance Message MyLayoutEvent Done. We also reimplement the dynamic type check while we're here, to just directly use 'cast', rather than expose a raw fromDynamic/toDyn. With this, I'm much happier about out dynamically extensible layout event subsystem. ] { hunk ./Config.hs 157 - , ((modMask, xK_h ), layoutMsg Shrink) - , ((modMask, xK_l ), layoutMsg Expand) + , ((modMask, xK_h ), sendMessage Shrink) + , ((modMask, xK_l ), sendMessage Expand) hunk ./Operations.hs 19 -import Data.Dynamic ( Typeable, toDyn, fromDynamic ) hunk ./Operations.hs 77 +-- | Throw an (extensible) message value to the current Layout scheme, +-- possibly modifying how we layout the windows, then refresh. hunk ./Operations.hs 80 --- TODO, using Typeable for extensible stuff is a bit gunky. Check -- --- 'extensible exceptions' paper for other ideas. +-- TODO, this will refresh on Nothing. hunk ./Operations.hs 82 --- Basically this thing specifies the basic operations that vary between --- layouts. --- -data ShrinkOrExpand = Shrink | Expand deriving (Typeable, Eq) - -layoutMsg :: Typeable a => a -> X () -- FIXME: The below shouldn't refresh on Nothing -layoutMsg a = layout $ \x@(l:ls) -> maybe x (:ls) (modifyLayout l (toDyn a)) +sendMessage :: Message a => a -> X () +sendMessage m = layout $ \xs -> case xs of + [] -> [] + (l:ls) -> maybe xs (:ls) $ modifyLayout l (SomeMessage m) hunk ./Operations.hs 87 +------------------------------------------------------------------------ hunk ./Operations.hs 89 --- Standard layout algorithms: +-- Builtin layout algorithms: hunk ./Operations.hs 94 +-- +-- The latter algorithms support the following operations: hunk ./Operations.hs 97 -full :: Layout -tall, wide :: Rational -> Rational -> Layout +-- Shrink +-- Expand +-- + +data Resize = Shrink | Expand deriving (Typeable, Show) +instance Message Resize hunk ./Operations.hs 104 -full = Layout { doLayout = \sc ws -> [ (w,sc) | w <- ws ] - , modifyLayout = const Nothing } +full :: Layout +full = Layout { doLayout = \sc ws -> [ (w,sc) | w <- ws ] + , modifyLayout = const Nothing } -- no changes hunk ./Operations.hs 108 +tall, wide :: Rational -> Rational -> Layout hunk ./Operations.hs 112 - , modifyLayout = fmap f . fromDynamic } + , modifyLayout = fmap handler . fromMessage } hunk ./Operations.hs 114 - where f s = tall delta ((op s) frac delta) - op Shrink = (-) ; op Expand = (+) + where handler s = tall delta $ (case s of + Shrink -> (-) + Expand -> (+)) frac delta hunk ./XMonad.hs 20 + Typeable, Message, SomeMessage(..), fromMessage, hunk ./XMonad.hs 32 -import Data.Dynamic ( Dynamic ) +import Data.Typeable hunk ./XMonad.hs 40 - , layouts :: !(M.Map WorkspaceId [Layout]) -- ^ mapping of workspaces + , layouts :: !(M.Map WorkspaceId [Layout]) } -- ^ mapping of workspaces hunk ./XMonad.hs 42 - } hunk ./XMonad.hs 54 - , focusedBorder :: !Color -- ^ border color of the focused window - } + , focusedBorder :: !Color } -- ^ border color of the focused window hunk ./XMonad.hs 96 --- 'doLayout', a pure function to layout a Window set --- 'modifyLayout', +-- 'doLayout', a pure function to layout a Window set 'modifyLayout', +-- 'modifyLayout' can be considered a branch of an exception handler. +-- hunk ./XMonad.hs 100 - , modifyLayout :: Dynamic -> Maybe Layout } + , modifyLayout :: SomeMessage -> Maybe Layout } + +-- Based on ideas in /An Extensible Dynamically-Typed Hierarchy of Exceptions/, +-- Simon Marlow, 2006. Use extensible messages to the modifyLayout handler. +-- +-- User-extensible messages must be a member of this class: +-- +class (Typeable a, Show a) => Message a + +-- +-- A wrapped value of some type in the Message class. +-- +data SomeMessage = forall a. Message a => SomeMessage a + +-- +-- And now, unwrap a given, unknown Message type, performing a (dynamic) +-- type check on the result. +-- +fromMessage :: Message m => SomeMessage -> Maybe m +fromMessage (SomeMessage m) = cast m } Context: [refactoring, style, comments on new layout code Don Stewart **20070504023618] [use anyKey constant instead of magic number Jason Creighton **20070504015043] [added mirrorLayout to mirror arbitrary layouts Jason Creighton **20070504014653] [Fix layout switching order Spencer Janssen **20070503235632] [More Config.hs bugs Spencer Janssen **20070503234607] [Revert accidental change to Config.hs Spencer Janssen **20070503233148] [Add -fglasgow-exts for pattern guards. Properties.hs doesn't complain anymore Spencer Janssen **20070503214221] [Avoid the unsafe pattern match, in case Config.hs has no layouts Spencer Janssen **20070503214007] [add support for extensible layouts. David Roundy **20070503144750] [comments. and stop tracing events to stderr Don Stewart **20070503075821] [-Wall police Don Stewart **20070503074937] [elaborate documentation in Config.hs Don Stewart **20070503074843] [Use updated refreshKeyboardMapping. Requires latest X11-extras Spencer Janssen **20070503032040] [run QC tests in addition to LOC test Jason Creighton **20070503003202] [Add 'mod-n': refreshes current layout Spencer Janssen **20070503002252] [Fix tests after StackSet changes Spencer Janssen **20070502201622] [First steps to adding floating layer Spencer Janssen **20070502195917] [update motivational text using xmonad.org Don Stewart **20070502061859] [Sort dependencies in installation order Spencer Janssen **20070501204249] [Recommend X11-extras 0.1 Spencer Janssen **20070501204121] [elaborate description in .cabal Don Stewart **20070501035414] [use -fasm by default. Much faster Don Stewart **20070501031220] [Make border width configurable Spencer Janssen **20070430163515] [Add Config.hs-boot, remove defaultLayoutDesc from XConf Spencer Janssen **20070430162647] [Comment only Spencer Janssen **20070430161635] [Comment only Spencer Janssen **20070430161511] [check we never generate invalid stack sets Don Stewart **20070430065946] [view n . shift n . view i . shift i) x == x --> shift + view is invertible Don Stewart **20070430062901] [add rotate all and view idempotency tests Don Stewart **20070430055751] [Add XConf for values that don't change. Spencer Janssen **20070430054715] [Control.Arrow is suspicious, add an explicit import Spencer Janssen **20070430053623] [push is idempotent Don Stewart **20070430054345] [add two properties relating to empty window managers Don Stewart **20070430051016] [configurable border colors Jason Creighton **20070430043859 This also fixes a bug where xmonad was assuming a 24-bit display, and just using, eg, 0xff0000 as an index into a colormap without querying the X server to determine the proper pixel value for "red". ] [new QC property: opening a window only affects the current screen Don Stewart **20070430050133] [a bit more precise about building non-empty stacksets for one test Don Stewart **20070430035729] [remove redundant call to 'delete' in 'shift' Don Stewart **20070430031151] [clean 'delete' a little Don Stewart **20070430025319] [shrink 'swap' Don Stewart **20070430024813] [shrink 'rotate' a little Don Stewart **20070430024525] [move size into Properties.hs Don Stewart **20070430021758] [don't need 'size' operation on StackSet Don Stewart **20070430015927] [avoid grabbing all keys when a keysym is undefined Jason Creighton **20070428180046 XKeysymToKeycode() returns zero if the keysym is undefined. Zero also happens to be the value of AnyKey. ] [add homepage: field to .cabal file Don Stewart **20070429041011] [add fromList to Properties.hs Don Stewart **20070429035823] [move fromList into Properties.hs, -17 loc Don Stewart **20070429035804] [Further refactoring Spencer Janssen **20070426212257] [Refactor in Config.hs (no real changes) Spencer Janssen **20070426211407] [Add the manpage to extra-source-files Spencer Janssen **20070426014105] [add xmonad manpage David Lazar **20070426010812] [Remove toList Spencer Janssen **20070426005713] [Ignore numlock and capslock in keybindings Jason Creighton **20070424013357] [Clear numlock bit Spencer Janssen **20070424010352] [force window border to 1px Jason Creighton **20070423050824] [s/creigh// Don Stewart **20070423024026] [some other things to do Don Stewart **20070423023151] [Start TODOs for 0.2 Spencer Janssen **20070423021526] [update readme Don Stewart **20070422090507] [TAG 0.1 Spencer Janssen **20070422083033] Patch bundle hash: 58f3c7c9b1d98e93c2a0aa388fd91f7ee5567446 From dons at cse.unsw.edu.au Fri May 4 04:07:52 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Fri May 4 04:05:06 2007 Subject: [Xmonad] Constrained dynamically extensible layout events: a patch In-Reply-To: <20070504080304.GC302@cse.unsw.EDU.AU> References: <20070504080304.GC302@cse.unsw.EDU.AU> Message-ID: <20070504080752.GD302@cse.unsw.EDU.AU> dons: > David, Spencer et al, are there any problems with restricting layoutMsg > arguments to being members of the (open) Message class? I'd (strongly) > prefer this over just Dynamic, since it restores most of the static > checking we'd need. Oh, I forgot an example. This is why Dynamic-only is scary: , ((modMask, xK_h ), layoutMsg "hey Joe!") , ((modMask, xK_l ), layoutMsg Expand) is well typed. Under the new system, it becomes a static error: Config.hs:157:43: No instance for (Message [Char]) arising from use of `sendMessage' at Config.hs:157:43-65 -- Don From dons at cse.unsw.edu.au Fri May 4 04:21:07 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Fri May 4 04:18:21 2007 Subject: [Xmonad] Constrained dynamically extensible layout events: a patch In-Reply-To: <20070504080752.GD302@cse.unsw.EDU.AU> References: <20070504080304.GC302@cse.unsw.EDU.AU> <20070504080752.GD302@cse.unsw.EDU.AU> Message-ID: <20070504082106.GE302@cse.unsw.EDU.AU> dons: > dons: > > David, Spencer et al, are there any problems with restricting layoutMsg > > arguments to being members of the (open) Message class? I'd (strongly) > > prefer this over just Dynamic, since it restores most of the static > > checking we'd need. > > Oh, I forgot an example. This is why Dynamic-only is scary: > > , ((modMask, xK_h ), layoutMsg "hey Joe!") > , ((modMask, xK_l ), layoutMsg Expand) > > is well typed. Under the new system, it becomes a static error: > > Config.hs:157:43: > No instance for (Message [Char]) > arising from use of `sendMessage' at Config.hs:157:43-65 > > -- Don Ah, and a version that actually applies, given Spencer's last changes. -- Don -------------- next part -------------- New patches: [Constrain layout messages to be members of a Message class Don Stewart **20070504081649 Using Typeables as the only constraint on layout messages is a bit scary, as a user can send arbitrary values to layoutMsg, whether they make sense or not: there's basically no type feedback on the values you supply to layoutMsg. Folloing Simon Marlow's dynamically extensible exceptions paper, we use an existential type, and a Message type class, to constrain valid arguments to layoutMsg to be valid members of Message. That is, a user writes some data type for messages their layout algorithm accepts: data MyLayoutEvent = Zoom | Explode | Flaming3DGlassEffect deriving (Typeable) and they then add this to the set of valid message types: instance Message MyLayoutEvent Done. We also reimplement the dynamic type check while we're here, to just directly use 'cast', rather than expose a raw fromDynamic/toDyn. With this, I'm much happier about out dynamically extensible layout event subsystem. ] { hunk ./Config.hs 157 - , ((modMask, xK_h ), layoutMsg Shrink) - , ((modMask, xK_l ), layoutMsg Expand) + , ((modMask, xK_h ), sendMessage Shrink) + , ((modMask, xK_l ), sendMessage Expand) hunk ./Operations.hs 19 -import Data.Dynamic ( Typeable, toDyn, fromDynamic ) hunk ./Operations.hs 75 -switchLayout = layout (\(x, xs) -> let xs' = xs ++ [x] - in (head xs', tail xs')) +switchLayout = layout (\(x, xs) -> let xs' = xs ++ [x] in (head xs', tail xs')) hunk ./Operations.hs 77 +-- | Throw an (extensible) message value to the current Layout scheme, +-- possibly modifying how we layout the windows, then refresh. hunk ./Operations.hs 80 --- TODO, using Typeable for extensible stuff is a bit gunky. Check -- --- 'extensible exceptions' paper for other ideas. +-- TODO, this will refresh on Nothing. hunk ./Operations.hs 82 --- Basically this thing specifies the basic operations that vary between --- layouts. --- -data ShrinkOrExpand = Shrink | Expand deriving (Typeable, Eq) - -layoutMsg :: Typeable a => a -> X () -- FIXME: The below shouldn't refresh on Nothing -layoutMsg a = layout $ \x@(l, ls) -> maybe x (flip (,) ls) (modifyLayout l (toDyn a)) +sendMessage :: Message a => a -> X () +sendMessage a = layout $ \x@(l, ls) -> maybe x (flip (,) ls) (modifyLayout l (SomeMessage a)) hunk ./Operations.hs 85 +------------------------------------------------------------------------ hunk ./Operations.hs 87 --- Standard layout algorithms: +-- Builtin layout algorithms: hunk ./Operations.hs 92 +-- +-- The latter algorithms support the following operations: hunk ./Operations.hs 95 -full :: Layout -tall, wide :: Rational -> Rational -> Layout +-- Shrink +-- Expand +-- + +data Resize = Shrink | Expand deriving (Typeable, Show) +instance Message Resize hunk ./Operations.hs 102 -full = Layout { doLayout = \sc ws -> [ (w,sc) | w <- ws ] - , modifyLayout = const Nothing } +full :: Layout +full = Layout { doLayout = \sc ws -> [ (w,sc) | w <- ws ] + , modifyLayout = const Nothing } -- no changes hunk ./Operations.hs 106 +tall, wide :: Rational -> Rational -> Layout hunk ./Operations.hs 110 - , modifyLayout = fmap f . fromDynamic } + , modifyLayout = fmap handler . fromMessage } hunk ./Operations.hs 112 - where f s = tall delta ((op s) frac delta) - op Shrink = (-) ; op Expand = (+) + where handler s = tall delta $ (case s of + Shrink -> (-) + Expand -> (+)) frac delta hunk ./XMonad.hs 20 + Typeable, Message, SomeMessage(..), fromMessage, hunk ./XMonad.hs 32 -import Data.Dynamic ( Dynamic ) +import Data.Typeable hunk ./XMonad.hs 40 - , layouts :: !(M.Map WorkspaceId (Layout, [Layout])) - -- ^ mapping of workspaces - -- to descriptions of their layouts - } + , layouts :: !(M.Map WorkspaceId (Layout, [Layout])) } + -- ^ mapping of workspaces to descriptions of their layouts hunk ./XMonad.hs 54 - , focusedBorder :: !Color -- ^ border color of the focused window - } + , focusedBorder :: !Color } -- ^ border color of the focused window hunk ./XMonad.hs 96 --- 'doLayout', a pure function to layout a Window set --- 'modifyLayout', +-- 'doLayout', a pure function to layout a Window set 'modifyLayout', +-- 'modifyLayout' can be considered a branch of an exception handler. +-- hunk ./XMonad.hs 100 - , modifyLayout :: Dynamic -> Maybe Layout } + , modifyLayout :: SomeMessage -> Maybe Layout } + +-- Based on ideas in /An Extensible Dynamically-Typed Hierarchy of Exceptions/, +-- Simon Marlow, 2006. Use extensible messages to the modifyLayout handler. +-- +-- User-extensible messages must be a member of this class: +-- +class (Typeable a, Show a) => Message a + +-- +-- A wrapped value of some type in the Message class. +-- +data SomeMessage = forall a. Message a => SomeMessage a + +-- +-- And now, unwrap a given, unknown Message type, performing a (dynamic) +-- type check on the result. +-- +fromMessage :: Message m => SomeMessage -> Maybe m +fromMessage (SomeMessage m) = cast m } Context: [Handle empty layout lists Spencer Janssen **20070504045644] [refactoring, style, comments on new layout code Don Stewart **20070504023618] [use anyKey constant instead of magic number Jason Creighton **20070504015043] [added mirrorLayout to mirror arbitrary layouts Jason Creighton **20070504014653] [Fix layout switching order Spencer Janssen **20070503235632] [More Config.hs bugs Spencer Janssen **20070503234607] [Revert accidental change to Config.hs Spencer Janssen **20070503233148] [Add -fglasgow-exts for pattern guards. Properties.hs doesn't complain anymore Spencer Janssen **20070503214221] [Avoid the unsafe pattern match, in case Config.hs has no layouts Spencer Janssen **20070503214007] [add support for extensible layouts. David Roundy **20070503144750] [comments. and stop tracing events to stderr Don Stewart **20070503075821] [-Wall police Don Stewart **20070503074937] [elaborate documentation in Config.hs Don Stewart **20070503074843] [Use updated refreshKeyboardMapping. Requires latest X11-extras Spencer Janssen **20070503032040] [run QC tests in addition to LOC test Jason Creighton **20070503003202] [Add 'mod-n': refreshes current layout Spencer Janssen **20070503002252] [Fix tests after StackSet changes Spencer Janssen **20070502201622] [First steps to adding floating layer Spencer Janssen **20070502195917] [update motivational text using xmonad.org Don Stewart **20070502061859] [Sort dependencies in installation order Spencer Janssen **20070501204249] [Recommend X11-extras 0.1 Spencer Janssen **20070501204121] [elaborate description in .cabal Don Stewart **20070501035414] [use -fasm by default. Much faster Don Stewart **20070501031220] [Make border width configurable Spencer Janssen **20070430163515] [Add Config.hs-boot, remove defaultLayoutDesc from XConf Spencer Janssen **20070430162647] [Comment only Spencer Janssen **20070430161635] [Comment only Spencer Janssen **20070430161511] [check we never generate invalid stack sets Don Stewart **20070430065946] [view n . shift n . view i . shift i) x == x --> shift + view is invertible Don Stewart **20070430062901] [add rotate all and view idempotency tests Don Stewart **20070430055751] [Add XConf for values that don't change. Spencer Janssen **20070430054715] [Control.Arrow is suspicious, add an explicit import Spencer Janssen **20070430053623] [push is idempotent Don Stewart **20070430054345] [add two properties relating to empty window managers Don Stewart **20070430051016] [configurable border colors Jason Creighton **20070430043859 This also fixes a bug where xmonad was assuming a 24-bit display, and just using, eg, 0xff0000 as an index into a colormap without querying the X server to determine the proper pixel value for "red". ] [new QC property: opening a window only affects the current screen Don Stewart **20070430050133] [a bit more precise about building non-empty stacksets for one test Don Stewart **20070430035729] [remove redundant call to 'delete' in 'shift' Don Stewart **20070430031151] [clean 'delete' a little Don Stewart **20070430025319] [shrink 'swap' Don Stewart **20070430024813] [shrink 'rotate' a little Don Stewart **20070430024525] [move size into Properties.hs Don Stewart **20070430021758] [don't need 'size' operation on StackSet Don Stewart **20070430015927] [avoid grabbing all keys when a keysym is undefined Jason Creighton **20070428180046 XKeysymToKeycode() returns zero if the keysym is undefined. Zero also happens to be the value of AnyKey. ] [add homepage: field to .cabal file Don Stewart **20070429041011] [add fromList to Properties.hs Don Stewart **20070429035823] [move fromList into Properties.hs, -17 loc Don Stewart **20070429035804] [Further refactoring Spencer Janssen **20070426212257] [Refactor in Config.hs (no real changes) Spencer Janssen **20070426211407] [Add the manpage to extra-source-files Spencer Janssen **20070426014105] [add xmonad manpage David Lazar **20070426010812] [Remove toList Spencer Janssen **20070426005713] [Ignore numlock and capslock in keybindings Jason Creighton **20070424013357] [Clear numlock bit Spencer Janssen **20070424010352] [force window border to 1px Jason Creighton **20070423050824] [s/creigh// Don Stewart **20070423024026] [some other things to do Don Stewart **20070423023151] [Start TODOs for 0.2 Spencer Janssen **20070423021526] [update readme Don Stewart **20070422090507] [TAG 0.1 Spencer Janssen **20070422083033] Patch bundle hash: 28177163852c07f1fc191ac89148c43e45866f30 From dave at nullcube.com Fri May 4 05:59:02 2007 From: dave at nullcube.com (Dave Harrison) Date: Fri May 4 05:56:16 2007 Subject: [Xmonad] A dock in xmonad Message-ID: <463B03E6.7090904@nullcube.com> Hi all, I was just wondering, are there any plans or ideas about how a dock could be incorporated into xmonad ? Is there a 3rd party dock that could be used ? Cheers Dave From dons at cse.unsw.edu.au Fri May 4 06:03:42 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Fri May 4 06:00:55 2007 Subject: [Xmonad] A dock in xmonad In-Reply-To: <463B03E6.7090904@nullcube.com> References: <463B03E6.7090904@nullcube.com> Message-ID: <20070504100342.GA1892@cse.unsw.EDU.AU> dave: > Hi all, > > I was just wondering, are there any plans or ideas about how a dock could be > incorporated into xmonad ? Is there a 3rd party dock that could be used ? > > Cheers > Dave What kind of behaviour would it have? -- Don From dave at nullcube.com Fri May 4 06:29:04 2007 From: dave at nullcube.com (Dave Harrison) Date: Fri May 4 06:26:17 2007 Subject: [Xmonad] A dock in xmonad In-Reply-To: <20070504100342.GA1892@cse.unsw.EDU.AU> References: <463B03E6.7090904@nullcube.com> <20070504100342.GA1892@cse.unsw.EDU.AU> Message-ID: <463B0AF0.8000706@nullcube.com> Donald Bruce Stewart wrote: > dave: >> Hi all, >> >> I was just wondering, are there any plans or ideas about how a dock could be >> incorporated into xmonad ? Is there a 3rd party dock that could be used ? >> >> Cheers >> Dave > > What kind of behaviour would it have? Primarily I'm looking for something that will grab and contain the "dock icons" that alot of programs provide (I'm thinking things like amarok, most instant messenger clients [kopete, gaim etc], most power management tools, volume controls etc etc). I'm sure it's more complex than it sounds, but there's no more behaviour I'd want from such a dock than the above. From dave at nullcube.com Fri May 4 06:45:27 2007 From: dave at nullcube.com (Dave Harrison) Date: Fri May 4 06:42:40 2007 Subject: [Xmonad] A dock in xmonad In-Reply-To: <463B0AF0.8000706@nullcube.com> References: <463B03E6.7090904@nullcube.com> <20070504100342.GA1892@cse.unsw.EDU.AU> <463B0AF0.8000706@nullcube.com> Message-ID: <463B0EC7.9080004@nullcube.com> Dave Harrison wrote: > Donald Bruce Stewart wrote: >> dave: >>> Hi all, >>> >>> I was just wondering, are there any plans or ideas about how a dock could be >>> incorporated into xmonad ? Is there a 3rd party dock that could be used ? >>> >>> Cheers >>> Dave >> What kind of behaviour would it have? > > Primarily I'm looking for something that will grab and contain the "dock icons" > that alot of programs provide (I'm thinking things like amarok, most instant > messenger clients [kopete, gaim etc], most power management tools, volume > controls etc etc). > > I'm sure it's more complex than it sounds, but there's no more behaviour I'd > want from such a dock than the above. I've also just had a friend point this link out to me, that acts as a standard for how docks and other desktop components need to behave http://standards.freedesktop.org/wm-spec/wm-spec-latest.html From droundy at darcs.net Fri May 4 10:05:15 2007 From: droundy at darcs.net (David Roundy) Date: Fri May 4 10:02:28 2007 Subject: [Xmonad] statically checked non-empty layout lists In-Reply-To: <20070504041635.GG31335@cse.unsw.EDU.AU> References: <20070504040841.GF31335@cse.unsw.EDU.AU> <20070504041635.GG31335@cse.unsw.EDU.AU> Message-ID: <20070504140514.GB31509@abridgegame.org> On Fri, May 04, 2007 at 02:16:35PM +1000, Donald Bruce Stewart wrote: > dons: > > The new layout code introduces more chances for runtime errors than I'd > > like. In particular, the Dynamic type, and the possibility of users > > defining empty layout lists. > > And a patch, just so its archived somewhere. I'd vote yes on this. Only I'd prefer an infix constructor for Cons, such as :.: or something, so pattern matching will be prettier. -- David Roundy http://www.darcs.net From droundy at darcs.net Fri May 4 10:10:30 2007 From: droundy at darcs.net (David Roundy) Date: Fri May 4 10:07:44 2007 Subject: [Xmonad] Constrained dynamically extensible layout events: a patch In-Reply-To: <20070504080752.GD302@cse.unsw.EDU.AU> References: <20070504080304.GC302@cse.unsw.EDU.AU> <20070504080752.GD302@cse.unsw.EDU.AU> Message-ID: <20070504141028.GC31509@abridgegame.org> On Fri, May 04, 2007 at 06:07:52PM +1000, Donald Bruce Stewart wrote: > dons: > > David, Spencer et al, are there any problems with restricting layoutMsg > > arguments to being members of the (open) Message class? I'd (strongly) > > prefer this over just Dynamic, since it restores most of the static > > checking we'd need. > > Oh, I forgot an example. This is why Dynamic-only is scary: > > , ((modMask, xK_h ), layoutMsg "hey Joe!") > , ((modMask, xK_l ), layoutMsg Expand) > > is well typed. Under the new system, it becomes a static error: > > Config.hs:157:43: > No instance for (Message [Char]) > arising from use of `sendMessage' at Config.hs:157:43-65 I personally like the ability to send unaccepted messages. It can't pose a problem on the receiving end, since every layout has to be able to handle messages it knows nothing about. So the only danger is foolish users who send messages that have no effect, but that really seems harmless to me. I guess getting better error checking is nice, but it seems like you're talking about error checking for something that really isn't likely to be a problem. This is different from the NonEmpty list issue, which still is working on avoiding the dangers of foolish users--who define an empty layout list--but in that case those foolish users could actually crash xmonad, rather than simply defining a key binding that has no effect. -- David Roundy http://www.darcs.net From dons at cse.unsw.edu.au Fri May 4 10:20:07 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Fri May 4 10:17:19 2007 Subject: [Xmonad] Constrained dynamically extensible layout events: a patch In-Reply-To: <20070504141028.GC31509@abridgegame.org> References: <20070504080304.GC302@cse.unsw.EDU.AU> <20070504080752.GD302@cse.unsw.EDU.AU> <20070504141028.GC31509@abridgegame.org> Message-ID: <20070504142006.GA3515@cse.unsw.EDU.AU> droundy: > On Fri, May 04, 2007 at 06:07:52PM +1000, Donald Bruce Stewart wrote: > > dons: > > > David, Spencer et al, are there any problems with restricting layoutMsg > > > arguments to being members of the (open) Message class? I'd (strongly) > > > prefer this over just Dynamic, since it restores most of the static > > > checking we'd need. > > > > Oh, I forgot an example. This is why Dynamic-only is scary: > > > > , ((modMask, xK_h ), layoutMsg "hey Joe!") > > , ((modMask, xK_l ), layoutMsg Expand) > > > > is well typed. Under the new system, it becomes a static error: > > > > Config.hs:157:43: > > No instance for (Message [Char]) > > arising from use of `sendMessage' at Config.hs:157:43-65 > > I personally like the ability to send unaccepted messages. It can't pose a You can still send unaccepted messages, but you can't accidentally send a non-message type anymore. > problem on the receiving end, since every layout has to be able to handle > messages it knows nothing about. So the only danger is foolish users who Right. > send messages that have no effect, but that really seems harmless to me. I > guess getting better error checking is nice, but it seems like you're > talking about error checking for something that really isn't likely to be a > problem. Well, its pretty light, and more static checking is always good, in my view. This guides the user a bit more towards valid code. Is there any downside? > This is different from the NonEmpty list issue, which still is working on > avoiding the dangers of foolish users--who define an empty layout list--but > in that case those foolish users could actually crash xmonad, rather than > simply defining a key binding that has no effect. And that issue is fixed today, too, safeLayouts = case defaultLayouts of [] -> (full, []); (x:xs) -> (x, xs) I think the combination of a Message class, and the non-empty layout handled via another mechanism, covers the holes we opened up. -- Don From stefanor at cox.net Fri May 4 18:27:34 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Fri May 4 18:24:44 2007 Subject: [Xmonad] Constrained dynamically extensible layout events: a patch In-Reply-To: <20070504142006.GA3515@cse.unsw.EDU.AU> References: <20070504080304.GC302@cse.unsw.EDU.AU> <20070504080752.GD302@cse.unsw.EDU.AU> <20070504141028.GC31509@abridgegame.org> <20070504142006.GA3515@cse.unsw.EDU.AU> Message-ID: <20070504222734.GA2770@localhost.localdomain> On Sat, May 05, 2007 at 12:20:07AM +1000, Donald Bruce Stewart wrote: > Well, its pretty light, and more static checking is always good, in my view. > This guides the user a bit more towards valid code. Is there any downside? It makes the code more complicated without IMO sufficient justification. Stefan From jcreigh at gmail.com Sat May 5 13:45:16 2007 From: jcreigh at gmail.com (Jason Creighton) Date: Sat May 5 13:42:28 2007 Subject: [Xmonad] darcs patch: make Properties.hs exit with failure on test failure Message-ID: Sat May 5 11:43:57 MDT 2007 Jason Creighton * make Properties.hs exit with failure on test failure -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 8361 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/xmonad/attachments/20070505/72b1b0b3/attachment.bin From droundy at darcs.net Sat May 5 13:58:56 2007 From: droundy at darcs.net (David Roundy) Date: Sat May 5 13:56:05 2007 Subject: [Xmonad] darcs patch: make quickcheck tests friendlier to read. Message-ID: Hi all, This is just a silly patch to make it easier to deal with failed quickcheck properties in ghci. Derives a read instance for StackSet, and makes windows T be Char, so they're easier to distinguish when a StackSet is printed. David Sat May 5 10:54:15 PDT 2007 David Roundy * make quickcheck tests friendlier to read. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 8497 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/xmonad/attachments/20070505/346e758a/attachment.bin From droundy at darcs.net Sat May 5 14:02:11 2007 From: droundy at darcs.net (David Roundy) Date: Sat May 5 13:59:19 2007 Subject: [Xmonad] darcs patch: keep focus stack. Message-ID: Hi all, Here's a cut at a focus stack. It's a bit crude, but seems to work. I had to tweak the rotate properties, since rotating the focus (obviously) changes the focus stack. I don't think this weakening of those checks is really a Bad Thing. And I'm a little puzzled how prop_delete_push ever passed. Maybe it failed, and noone noticed? Or maybe we aren't running enough tests with large enough stack sizes, so we never ran into the case where the focus wasn't on the master window to start with? I don't know, but it suggests something is wrong. David P.S. Sorry for my crude code. If we like this behavior, we can clean it up. Sat May 5 10:57:09 PDT 2007 David Roundy * keep focus stack. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 12688 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/xmonad/attachments/20070505/95f03b9b/attachment-0001.bin From droundy at darcs.net Sat May 5 14:13:01 2007 From: droundy at darcs.net (David Roundy) Date: Sat May 5 14:10:12 2007 Subject: [Xmonad] idea for float layer and extensible layout Message-ID: <20070505181259.GA13099@abridgegame.org> I had an idea. What if we implement the float layer via (an extended) extensible layout scheme? It seems pretty straightforward to write a higher order layout that partitions windows between two Layouts, in which case with a little bit of care we ought to be able to just write a layout that handles floating windows only, and then composit that together with any other layout. I doubt this would be the way to *start* implementing a floating layer, but it seems like doing this as a refactor afterwards would both maintain the cleanliness of the code, and ensure the extensible layout interface is sufficiently powerful and flexible to handle just about any window-managing interface. One feature we'd obviously need would be the ability to specify the stacking order of the windows independently of the focus--which would argue in favor of jcreigh's idea that we ought to pass the focussed window to doLayout. But, of course, there's a whole lot more than that which would need doing as well--most notably, the ability for the layout to draw window decorations and respond to mouse events. But these would also need doing by a tabbed interface, which is of much more interest to me than a floating layer. This idea would also have the benefit of keeping xmonad small, since the floating layer could (and would) be implemented outside of the core, as a module imported into Config.hs. -- David Roundy http://www.darcs.net From droundy at darcs.net Sat May 5 14:56:31 2007 From: droundy at darcs.net (David Roundy) Date: Sat May 5 14:53:40 2007 Subject: [Xmonad] darcs patch: fix commend in RotView. Message-ID: Sat May 5 11:56:12 PDT 2007 David Roundy * fix commend in RotView. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 1688 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/xmonad/attachments/20070505/cc741967/attachment.bin From droundy at darcs.net Sat May 5 14:57:15 2007 From: droundy at darcs.net (David Roundy) Date: Sat May 5 14:54:24 2007 Subject: [Xmonad] darcs patch: fix commend in RotView. Message-ID: This one is amended... Sat May 5 11:56:54 PDT 2007 David Roundy * fix commend in RotView. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 1691 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/xmonad/attachments/20070505/94a4ab39/attachment.bin From dons at cse.unsw.edu.au Sun May 6 00:58:48 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Sun May 6 00:55:57 2007 Subject: [Xmonad] darcs patch: keep focus stack. In-Reply-To: References: Message-ID: <20070506045848.GE1481@cse.unsw.EDU.AU> droundy: > Hi all, > > Here's a cut at a focus stack. It's a bit crude, but seems to work. I had > to tweak the rotate properties, since rotating the focus (obviously) > changes the focus stack. I don't think this weakening of those checks is > really a Bad Thing. And I'm a little puzzled how prop_delete_push ever > passed. Maybe it failed, and noone noticed? Or maybe we aren't running > enough tests with large enough stack sizes, so we never ran into the case > where the focus wasn't on the master window to start with? I don't know, > but it suggests something is wrong. Ah ha. The generator wasn't changed when focus was separate from the stack ordering, so *yes* we only generate StackSets with focus on the master window. The 'fromList' code for StackSet needs changing. Good work! -- Don From sjanssen at cse.unl.edu Sun May 6 01:00:48 2007 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Sun May 6 00:57:59 2007 Subject: [Xmonad] darcs patch: make Properties.hs exit with failure on test failure In-Reply-To: References: Message-ID: <20070506000048.446d3576@localhost> On Sat, 05 May 2007 11:45:16 -0600 Jason Creighton wrote: > Sat May 5 11:43:57 MDT 2007 Jason Creighton > * make Properties.hs exit with failure on test failure Applied. From sjanssen at cse.unl.edu Sun May 6 01:02:09 2007 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Sun May 6 00:59:21 2007 Subject: [Xmonad] darcs patch: make quickcheck tests friendlier to read. In-Reply-To: References: Message-ID: <20070506000209.580ec331@localhost> On Sat, 05 May 2007 10:58:56 -0700 David Roundy wrote: > Hi all, > > This is just a silly patch to make it easier to deal with failed > quickcheck properties in ghci. Derives a read instance for StackSet, > and makes windows T be Char, so they're easier to distinguish when a > StackSet is printed. > > David > > Sat May 5 10:54:15 PDT 2007 David Roundy > * make quickcheck tests friendlier to read. > Applied. From sjanssen at cse.unl.edu Sun May 6 01:04:53 2007 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Sun May 6 01:02:05 2007 Subject: [Xmonad] darcs patch: fix commend in RotView. In-Reply-To: References: Message-ID: <20070506000453.1f7bf06b@localhost> On Sat, 05 May 2007 11:57:15 -0700 David Roundy wrote: > This one is amended... > > Sat May 5 11:56:54 PDT 2007 David Roundy > * fix commend in RotView. > Applied. From dons at cse.unsw.edu.au Tue May 8 01:35:16 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Tue May 8 01:32:19 2007 Subject: [Xmonad] darcs patch: keep focus stack. In-Reply-To: References: Message-ID: <20070508053516.GA10768@cse.unsw.EDU.AU> droundy: > Hi all, > > Here's a cut at a focus stack. It's a bit crude, but seems to work. I had > to tweak the rotate properties, since rotating the focus (obviously) > changes the focus stack. I don't think this weakening of those checks is > really a Bad Thing. And I'm a little puzzled how prop_delete_push ever > passed. Maybe it failed, and noone noticed? Or maybe we aren't running > enough tests with large enough stack sizes, so we never ran into the case > where the focus wasn't on the master window to start with? I don't know, > but it suggests something is wrong. Yes. Thanks for thinking about this! Fixing the Arbitrary StackSet instance to set focus randomly on each workspace, fs <- sequence [ if null s then return Nothing else liftM Just (elements s) | s <- ls ] And then folding focus over each stac: foldr (\f s -> case f of Nothing -> s Just w -> raiseFocus w s) s fs We now have 3 QC properties failing, including the one making claims about the behaviour of focus/delete/push: 1 delete.push identity : Falsifiable after 2 tests 2 shift reversible : Falsifiable after 1 tests 3 promote only swaps : Falsifiable after 8 tests For 1. we know this is a bug wrt. what we want to implement, in terms of where focus goes on push >> delete. The others are likely to just be overly constrained QC properties. -- Don From ndmitchell at gmail.com Tue May 8 08:34:57 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue May 8 08:32:00 2007 Subject: [Xmonad] Haskell 98 compliance Message-ID: <404396ef0705080534u6f4deb5fl7a1b283b3aff79c8@mail.gmail.com> Hi, This patch makes the StackSet file Haskell 98 once more, by using list comprehensions instead of pattern guards. This patch has not been tested, so please do the test script first. Use of Haskell 98 makes your lambdas sleep better at night, knowing they are more portable. Thanks Neil -------------- next part -------------- A non-text attachment was scrubbed... Name: haskell_98_compliance.patch.gz Type: application/x-gzip Size: 3202 bytes Desc: not available Url : http://www.haskell.org/pipermail/xmonad/attachments/20070508/a5d3e762/haskell_98_compliance.patch.bin From ndmitchell at gmail.com Tue May 8 10:03:16 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue May 8 10:00:13 2007 Subject: [Xmonad] Proofs of StackSet Message-ID: <404396ef0705080703n1de84dfo37cf87f362e7928a@mail.gmail.com> Hi, {- ICFP referees look away now -} Dons asked me to check some of the StackSet code for potential pattern match errors, and indeed, there are some. I used Catch (http://www-users.cs.york.ac.uk/~ndm/catch/) to do all the testing. The first thing I had to do was apply a 2 line patch to get that module building with Yhc/nhc, to do with defaulting. Next I ran the program and found: 1) view related: * view calls error, this clearly makes it possible to crash. * raiseFocus calls view 2) head related: * promote calls head, in a potentially unsafe manner 3) tail related: * swap calls tail, again potentially unsafe. This one is easy to fix, simply use drop 1. This also means that promote could crash due to swap. 4) fromJust related: index calls fromJust, which means that it may crash. This means that all functions calling index are potentially unsafe, including: delete, insert, promote, push, shift, view, raiseFocus I took a look at delete, and it looks like the safety depends on the stacks and the cache all agreeing - plus possibly some other invariants. You could probably rewrite some of this code to be more rebust, and gain a proof of safety. 5) everything else: Everything else is safe, apart from (potentially) the Ord instances passed around - I abstracted them away for the testing of Data.Map. Realistically, I think you are fine on this point. This means you have a proof of pattern match safety for: screen, peekStack, empty, peek, member, rotate, workspace, visibleWorkspaces No changes were required for testing (other than the 2 line one for Yhc) - the test sits in a separate module and is very simple: main = screen ||| peekStack ||| index ||| empty ||| peek ||| push ||| delete ||| member ||| raiseFocus ||| rotate ||| promote ||| shift ||| view ||| workspace ||| insert ||| visibleWorkspaces ||| swap I hope some of that is useful to you. The testing is 100% automatic and pretty easy to run, once you have Yhc and Catch installed and configured. You have two choices related to pattern match failure: 1) Ignore it, guard against with QuickCheck 2) Prove it, using Catch You also have three options regarding Catch use: 1) Integrate the 2 line change, add the Catch module testing framework in so anyone with Catch installed can replicate these tests - and check you don't get worse. 2) Have a catch branch, which has the library driver and the patch. This would be a really small branch :-) 3) Don't do anything, I can continue to check things occasionally. I'm on #haskell as ndm, so let me know if you want any help running any of this. Thanks Neil From sjanssen at cse.unl.edu Tue May 8 11:35:34 2007 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Tue May 8 11:35:35 2007 Subject: [Xmonad] Proofs of StackSet In-Reply-To: <404396ef0705080703n1de84dfo37cf87f362e7928a@mail.gmail.com> References: <404396ef0705080703n1de84dfo37cf87f362e7928a@mail.gmail.com> Message-ID: <20070508103534.77f3b16d@localhost> On Tue, 8 May 2007 15:03:16 +0100 "Neil Mitchell" wrote: > Hi, > > {- ICFP referees look away now -} > > Dons asked me to check some of the StackSet code for potential pattern > match errors, and indeed, there are some. I used Catch > (http://www-users.cs.york.ac.uk/~ndm/catch/) to do all the testing. > > The first thing I had to do was apply a 2 line patch to get that > module building with Yhc/nhc, to do with defaulting. Next I ran the > program and found: > > 1) view related: > > * view calls error, this clearly makes it possible to crash. > > * raiseFocus calls view > > 2) head related: > > * promote calls head, in a potentially unsafe manner > > 3) tail related: > > * swap calls tail, again potentially unsafe. This one is easy to fix, > simply use drop 1. This also means that promote could crash due to > swap. > > 4) fromJust related: > > index calls fromJust, which means that it may crash. This means that > all functions calling index are potentially unsafe, including: delete, > insert, promote, push, shift, view, raiseFocus > > I took a look at delete, and it looks like the safety depends on the > stacks and the cache all agreeing - plus possibly some other > invariants. You could probably rewrite some of this code to be more > rebust, and gain a proof of safety. > > 5) everything else: > > Everything else is safe, apart from (potentially) the Ord instances > passed around - I abstracted them away for the testing of Data.Map. > Realistically, I think you are fine on this point. This means you have > a proof of pattern match safety for: > > screen, peekStack, empty, peek, member, rotate, workspace, > visibleWorkspaces I've applied patches that should fix all of these. > You also have three options regarding Catch use: > > 1) Integrate the 2 line change, add the Catch module testing framework > in so anyone with Catch installed can replicate these tests - and > check you don't get worse. > 2) Have a catch branch, which has the library driver and the patch. > This would be a really small branch :-) > 3) Don't do anything, I can continue to check things occasionally. I'd like to get this in the main repository. Can you send a patch (or some instructions)? Thanks, Spencer Janssen From kai.grossjohann at verizonbusiness.com Wed May 9 03:49:42 2007 From: kai.grossjohann at verizonbusiness.com (Kai Grossjohann) Date: Wed May 9 03:47:17 2007 Subject: [Xmonad] Compile error Message-ID: <86ejlqo2qx.fsf@ketchup.de.uu.net> I just ran "darcs pull", then configure, and then build. I get this compiler error: ketchup% runhaskell Setup.lhs build Preprocessing executables for xmonad-0.1... Building xmonad-0.1... [1 of 6] Compiling StackSet ( StackSet.hs, dist/build/xmonad/xmonad-tmp/StackSet.o ) StackSet.hs:221:0: Warning: Defined but not used: `isFloat' [3 of 6] Compiling Config[boot] ( Config.hs-boot, nothing ) [4 of 6] Compiling Operations ( Operations.hs, dist/build/xmonad/xmonad-tmp/Operatio ns.o ) [5 of 6] Compiling Config ( Config.hs, dist/build/xmonad/xmonad-tmp/Config.o ) [6 of 6] Compiling Main ( Main.hs, dist/build/xmonad/xmonad-tmp/Main.o ) Main.hs:157:32: Couldn't match expected type `Display' against inferred type `Event' In the first argument of `refreshKeyboardMapping', namely `e' In the second argument of `($)', namely `refreshKeyboardMapping e' In the expression: io $ (refreshKeyboardMapping e) tia, Kai From kai.grossjohann at verizonbusiness.com Wed May 9 03:49:22 2007 From: kai.grossjohann at verizonbusiness.com (Kai Grossjohann) Date: Wed May 9 03:47:18 2007 Subject: [Xmonad] 0.1: Missing border around some windows Message-ID: <86irb2o2rh.fsf@ketchup.de.uu.net> There is a red border around xterm windows when they have focus. This border is lacking for Emacs, Gaim, and Firefox windows. (And possibly others.) Running xmonad-0.1. Kai From timd at macquarie.com.au Wed May 9 04:18:44 2007 From: timd at macquarie.com.au (Tim Docker) Date: Wed May 9 04:15:46 2007 Subject: [Xmonad] Compile error In-Reply-To: <86ejlqo2qx.fsf@ketchup.de.uu.net> References: <86ejlqo2qx.fsf@ketchup.de.uu.net> Message-ID: I think you need a more recent version of the Xll-extras package. Tim -----Original Message----- From: xmonad-bounces@haskell.org [mailto:xmonad-bounces@haskell.org] On Behalf Of Kai Grossjohann Sent: Wednesday, 9 May 2007 5:50 PM To: xmonad@haskell.org Subject: [Xmonad] Compile error I just ran "darcs pull", then configure, and then build. I get this compiler error: ketchup% runhaskell Setup.lhs build Preprocessing executables for xmonad-0.1... Building xmonad-0.1... [1 of 6] Compiling StackSet ( StackSet.hs, dist/build/xmonad/xmonad-tmp/StackSet.o ) StackSet.hs:221:0: Warning: Defined but not used: `isFloat' [3 of 6] Compiling Config[boot] ( Config.hs-boot, nothing ) [4 of 6] Compiling Operations ( Operations.hs, dist/build/xmonad/xmonad-tmp/Operatio ns.o ) [5 of 6] Compiling Config ( Config.hs, dist/build/xmonad/xmonad-tmp/Config.o ) [6 of 6] Compiling Main ( Main.hs, dist/build/xmonad/xmonad-tmp/Main.o ) Main.hs:157:32: Couldn't match expected type `Display' against inferred type `Event' In the first argument of `refreshKeyboardMapping', namely `e' In the second argument of `($)', namely `refreshKeyboardMapping e' In the expression: io $ (refreshKeyboardMapping e) tia, Kai _______________________________________________ Xmonad mailing list Xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad From alec at thened.net Wed May 9 04:52:48 2007 From: alec at thened.net (Alec Berryman) Date: Wed May 9 04:49:55 2007 Subject: [Xmonad] Compile error In-Reply-To: <86ejlqo2qx.fsf@ketchup.de.uu.net> References: <86ejlqo2qx.fsf@ketchup.de.uu.net> Message-ID: <20070509085248.GA4689@thened.net> Kai Grossjohann on 2007-05-09 09:49:42 +0200: > [6 of 6] Compiling Main ( Main.hs, dist/build/xmonad/xmonad-tmp/Main.o ) > > Main.hs:157:32: > Couldn't match expected type `Display' > against inferred type `Event' > In the first argument of `refreshKeyboardMapping', namely `e' > In the second argument of `($)', namely `refreshKeyboardMapping e' > In the expression: io $ (refreshKeyboardMapping e) I don't think you have an up-to-date version of X11-extras. Last week or so X11-extras got a fixed version of refreshKeyboardMapping and the line of code ghc is dying on went into xmonad at the same time. From A.M.Gimblett at swansea.ac.uk Wed May 9 05:01:34 2007 From: A.M.Gimblett at swansea.ac.uk (Andy Gimblett) Date: Wed May 9 04:58:30 2007 Subject: [Xmonad] Compile error In-Reply-To: <20070509085248.GA4689@thened.net> References: <86ejlqo2qx.fsf@ketchup.de.uu.net> <20070509085248.GA4689@thened.net> Message-ID: <20070509090134.GB22922@cspcag2.swan.ac.uk> On Wed, May 09, 2007 at 04:52:48AM -0400, Alec Berryman wrote: > > I don't think you have an up-to-date version of X11-extras. Last week > or so X11-extras got a fixed version of refreshKeyboardMapping and the > line of code ghc is dying on went into xmonad at the same time. In case you're using the version from hackage (which I was until I hit the same problem), here's how to actually get the latest X11-extras: darcs get http://darcs.haskell.org/~sjanssen/X11-extras :-) You'll need to run autoconf & autoheader before configuring & building - check the README. -- Andy Gimblett Computer Science Department University of Wales Swansea http://www.cs.swan.ac.uk/~csandy/ From kai.grossjohann at verizonbusiness.com Wed May 9 05:18:10 2007 From: kai.grossjohann at verizonbusiness.com (Kai Grossjohann) Date: Wed May 9 05:15:16 2007 Subject: [Xmonad] Compile error In-Reply-To: <20070509090134.GB22922@cspcag2.swan.ac.uk> (Andy Gimblett's message of "Wed\, 09 May 2007 10\:01\:34 +0100") References: <86ejlqo2qx.fsf@ketchup.de.uu.net> <20070509085248.GA4689@thened.net> <20070509090134.GB22922@cspcag2.swan.ac.uk> Message-ID: <867irinynh.fsf@ketchup.de.uu.net> Andy Gimblett writes: > On Wed, May 09, 2007 at 04:52:48AM -0400, Alec Berryman wrote: >> >> I don't think you have an up-to-date version of X11-extras. Last week >> or so X11-extras got a fixed version of refreshKeyboardMapping and the >> line of code ghc is dying on went into xmonad at the same time. > > In case you're using the version from hackage (which I was until I hit > the same problem), here's how to actually get the latest X11-extras: Thank you, Alec and Andy. With the most recent version of X11-extras from darcs, it builds and installs and runs fine. Kai From kai.grossjohann at verizonbusiness.com Wed May 9 05:19:06 2007 From: kai.grossjohann at verizonbusiness.com (Kai Grossjohann) Date: Wed May 9 05:16:18 2007 Subject: [Xmonad] Re: 0.1: Missing border around some windows In-Reply-To: <86irb2o2rh.fsf@ketchup.de.uu.net> (Kai Grossjohann's message of "Wed\, 09 May 2007 09\:49\:22 +0200") References: <86irb2o2rh.fsf@ketchup.de.uu.net> Message-ID: <863b26nylx.fsf@ketchup.de.uu.net> For the record: This has been fixed in the most recent sources from darcs. Kai Kai Grossjohann writes: > There is a red border around xterm windows when they have focus. This > border is lacking for Emacs, Gaim, and Firefox windows. (And possibly > others.) > > Running xmonad-0.1. > > Kai From kai.grossjohann at verizonbusiness.com Wed May 9 05:32:44 2007 From: kai.grossjohann at verizonbusiness.com (Kai Grossjohann) Date: Wed May 9 05:30:23 2007 Subject: [Xmonad] Switch screens less often? Message-ID: <86y7jymjer.fsf@ketchup.de.uu.net> I find that xmonad switches screens too often for my taste. So I would like to try out new behavior. Has anyone implemented it already? If not, then I'd try to give it a go, but I don't know any Haskell... Specifically: * Currently, Mod-1 and friends may switch screens if that workspace is already visible on another screen. I would like to make them beep instead, and not change workspaces. * Currently, RotView switches screens when the next workspace in line is on another screen. I would like to make it skip such workspaces. Example: Say I am on screen 0, showing workspace 1. Screen 1 shows workspace 3. Then rotating to the right should show workspace 2, then workspace 4, skipping workspace 3. * I would like to retain the behavior of Mod-w, Mod-e, Mod-r switching screens. Kai From droundy at darcs.net Wed May 9 11:16:23 2007 From: droundy at darcs.net (David Roundy) Date: Wed May 9 11:13:19 2007 Subject: [Xmonad] Switch screens less often? In-Reply-To: <86y7jymjer.fsf@ketchup.de.uu.net> References: <86y7jymjer.fsf@ketchup.de.uu.net> Message-ID: <20070509151621.GA16231@abridgegame.org> On Wed, May 09, 2007 at 11:32:44AM +0200, Kai Grossjohann wrote: > * Currently, RotView switches screens when the next workspace in line > is on another screen. > > I would like to make it skip such workspaces. > > Example: Say I am on screen 0, showing workspace 1. Screen 1 shows > workspace 3. Then rotating to the right should show workspace 2, > then workspace 4, skipping workspace 3. I agree, this is entirely consistent with the philosophy of RotView (which is to only rotate through "interesting" workspaces, and one that you can already see isn't "interesting"). I only have one screen myself, so it hasn't been an issue for me. -- David Roundy http://www.darcs.net From sjanssen at cse.unl.edu Wed May 9 12:04:47 2007 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Wed May 9 12:04:36 2007 Subject: [Xmonad] Re: 0.1: Missing border around some windows In-Reply-To: <863b26nylx.fsf@ketchup.de.uu.net> References: <86irb2o2rh.fsf@ketchup.de.uu.net> <863b26nylx.fsf@ketchup.de.uu.net> Message-ID: <20070509110447.0785767c@localhost> On Wed, 09 May 2007 11:19:06 +0200 Kai Grossjohann wrote: > For the record: This has been fixed in the most recent sources from > darcs. Yes, we fixed a few key bugs mere days after the 0.1 release :(. We should think about getting 0.2 out soon. Cheers, Spencer Janssen From codesite-noreply at google.com Wed May 9 18:29:37 2007 From: codesite-noreply at google.com (codesite-noreply@google.com) Date: Wed May 9 18:26:29 2007 Subject: [Xmonad] Issue 6 in project xmonad Message-ID: <163600d68504301111be321a2d360@google.com> Issue 6: Xmonad does not respect size hints http://code.google.com/p/xmonad/issues/detail?id=6 New issue report by stefa...@cox.net: Darcs xmonad does not respect size hints and will try to make everything fill the size allotment; this is annoying and ugly with xterm / emacs, and greatly reduces usability for imagemagick 'display' and xpdf's find. Issue attributes: Status: New Owner: ---- Labels: Type-Defect Priority-Medium -- 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 From codesite-noreply at google.com Wed May 9 18:56:41 2007 From: codesite-noreply at google.com (codesite-noreply@google.com) Date: Wed May 9 18:53:34 2007 Subject: [Xmonad] Issue 6 in project xmonad Message-ID: <163600d8e4043011728e2c77101462@google.com> Issue 6: Xmonad does not respect size hints http://code.google.com/p/xmonad/issues/detail?id=6 Comment #1 by quilotta: I made a quick & dirty patch for size hints: http://www.haskell.org/pipermail/xmonad/2007-May/000132.html Though you'll find that xpdf and imagemagick don't set useful size hints. -- 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 From jcreigh at gmail.com Wed May 9 21:27:58 2007 From: jcreigh at gmail.com (Jason Creighton) Date: Wed May 9 21:24:54 2007 Subject: [Xmonad] darcs patch: make rotView only consider non-visible workspaces (Xin... Message-ID: Wed May 9 19:20:59 MDT 2007 Jason Creighton * make rotView only consider non-visible workspaces (Xinerama) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 2703 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/xmonad/attachments/20070509/2506462e/attachment.bin From jcreigh at gmail.com Wed May 9 21:41:35 2007 From: jcreigh at gmail.com (Jason Creighton) Date: Wed May 9 21:38:36 2007 Subject: [Xmonad] Switch screens less often? In-Reply-To: <86y7jymjer.fsf@ketchup.de.uu.net> References: <86y7jymjer.fsf@ketchup.de.uu.net> Message-ID: <20070510014135.GA20259@jpc.example.com> On Wed, May 09, 2007 at 11:32:44AM +0200, Kai Grossjohann wrote: > I find that xmonad switches screens too often for my taste. So I > would like to try out new behavior. Has anyone implemented it > already? If not, then I'd try to give it a go, but I don't know any > Haskell... > > Specifically: > > * Currently, Mod-1 and friends may switch screens if that workspace is > already visible on another screen. > > I would like to make them beep instead, and not change workspaces. I don't think anybody has implemented this. I don't see why you'd want to, but if you want this behavior, probably the easiest way to go about it would be to write a wrapper around "view" that checks if the workspace you're switching to is already visible and beeps (or whatever) if it is. Something like: (completely untested) myview :: WorkspaceId -> X () myview n = do ws <- gets workspace if n `elem` W.visibleWorkspaces ws then -- beep somehow else view n ...and then change your mod-[1..9] bindings to use "myview" instead of "view" > * Currently, RotView switches screens when the next workspace in line > is on another screen. > > I would like to make it skip such workspaces. > > Example: Say I am on screen 0, showing workspace 1. Screen 1 shows > workspace 3. Then rotating to the right should show workspace 2, > then workspace 4, skipping workspace 3. Good idea! I sent a patch to do this...it should show up in XMonadContrib shortly. > * I would like to retain the behavior of Mod-w, Mod-e, Mod-r switching > screens. That should be easy. :) Jason Creighton From jcreigh at gmail.com Wed May 9 23:37:48 2007 From: jcreigh at gmail.com (Jason Creighton) Date: Wed May 9 23:34:45 2007 Subject: [Xmonad] darcs patch: bump LOC limit to 550 (and 1 more) Message-ID: Wed May 9 21:27:31 MDT 2007 Jason Creighton * bump LOC limit to 550 Wed May 9 21:36:20 MDT 2007 Jason Creighton * Swap workspaces instead of switching screens Previously, xmonad if workspace 1 and 2 were visible on screens 1 and 2, and workspace 1 was the current workspace, mod-2 would simply simple switch focus to screen 2. The new behavior is to always show the workspace you're switching to on the current screen. If the new workspace was visible on another screen, the formerly-current workspace will appear on that screen. In the example above, workspace 2 would appear on screen 1 and workspace 1 would appear on screen 2. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 11912 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/xmonad/attachments/20070509/bc9644c4/attachment-0001.bin From sjanssen at cse.unl.edu Thu May 10 02:39:16 2007 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Thu May 10 02:36:24 2007 Subject: [Xmonad] darcs patch: make rotView only consider non-visible workspaces (Xin... In-Reply-To: References: Message-ID: <20070510013916.5b1c081c@localhost> On Wed, 09 May 2007 19:27:58 -0600 Jason Creighton wrote: > Wed May 9 19:20:59 MDT 2007 Jason Creighton > * make rotView only consider non-visible workspaces (Xinerama) Applied. From sjanssen at cse.unl.edu Thu May 10 03:00:55 2007 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Thu May 10 02:57:53 2007 Subject: [Xmonad] darcs patch: bump LOC limit to 550 (and 1 more) In-Reply-To: References: Message-ID: <20070510020055.7eae0dec@localhost> On Wed, 09 May 2007 21:37:48 -0600 Jason Creighton wrote: > Wed May 9 21:36:20 MDT 2007 Jason Creighton > * Swap workspaces instead of switching screens > Previously, xmonad if workspace 1 and 2 were visible on screens 1 > and 2, and workspace 1 was the current workspace, mod-2 would simply > simple switch focus to screen 2. > > The new behavior is to always show the workspace you're switching > to on the current screen. If the new workspace was visible on another > screen, the formerly-current workspace will appear on that screen. In > the example above, workspace 2 would appear on screen 1 and workspace > 1 would appear on screen 2. It's hard to say whether this is an improvement, so I'm going to try this patch out for a couple days before applying it to the main repo. Comments about this change are solicited. Cheers, Spencer Janssen From kai.grossjohann at verizonbusiness.com Thu May 10 03:01:15 2007 From: kai.grossjohann at verizonbusiness.com (Kai Grossjohann) Date: Thu May 10 02:58:20 2007