[Xmonad] darcs patch: refactor layout interface. (and 1 more)

[David Roundy]

On Wed, Apr 18, 2007 at 07:06:11PM -0600, Jason Creighton wrote:
> On Wed, Apr 18, 2007 at 09:05:56AM -0700, David Roundy wrote:
> > hunk ./Operations.hs 49
> > -            case layoutType fl of
> > -                Full -> fmap (flip (,) sc) $ maybeToList $ W.peekStack n ws
> > -                Tall -> tile  (tileFraction fl) sc $ W.index n ws
> > -                Wide -> vtile (tileFraction fl) sc $ W.index n ws
> > +            (doLayout l) sc $ W.index n ws
> >          whenJust (W.peekStack n ws) (io . raiseWindow d)
> >      whenJust (W.peek ws) setFocus
> >      clearEnterEvents
> > hunk ./Operations.hs 54
> >  
> > +full :: Layout
> > +full = Layout { doLayout = \sc -> map (\w -> (w,sc)), modifyLayout = const Nothing }
> 
> If I'm reading this correctly, I don't think that will work. "full"
> doesn't display the first window in the tiling order, it displays the
> focused window. So Rectangle -> [Window] -> [(Window, Rectangle)] is not
> sufficient to support all the cases we have now: The layout function has
> to somehow know which window is focus. To that end, I think the layout
> function type is going to have to be something like

I can assure you that full does work (I just double-checked), although I
couldn't really explain why--except experimentally.  (By which I mean that
it displays the focussed window, and no other.)  Perhaps the focussed
window is always displayed on top of the other windows when they overlap?

> Rectangle -> Workspace -> [(Window, Rectangle)]
> 
> ...where "Workspace" is a magical, as-yet-non-existent datatype that
> contains a list of windows, which one is focused and the layout
> description. (Possibly other stuff; that's all I can think of ATM.) And
> of course StackSet would have to be modified to use "Workspace".

We certainly could generalize, but I don't think we need a new datatype for
this.  As far as I can see, all we would need to add is an index to the
focussed window, since that's all the information that is stored.

I'm not sure what you mean by the "layout description".  My idea (as
exemplified in this patch) is that you don't need a layout description, and
I don't want one--assuming you mean something like a data type.

> In that scenario, I'm not quite sure where you'd want to parameterize
> your user-defined message type. Indeed, I'm not quite sure what to do
> about that in the first place. If the whole X monad takes this type,
> doesn't that mean that you made up a totally new type, you couldn't mix
> and match your layout functions with the builtin ones?

In the scenario I'm imagining, layout functions would define a class
describing the messages they accept, and the Config file would define a
data type that is an instance of all those classes.  Thus we can have any
combination of layouts, which can each accept any number of messages.  The
Config file needs to "know" the details of the messages in order to set up
key bindings anyhow.

In practice, there probably won't be very many such classes, since most
layouts will accept similar commands.
-- 
David Roundy
http://www.darcs.net