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

[David Roundy]

On Thu, Apr 19, 2007 at 07:10:36PM -0600, Jason Creighton wrote:
> On Wed, Apr 18, 2007 at 09:27:03PM -0700, David Roundy wrote:
> > On Wed, Apr 18, 2007 at 07:06:11PM -0600, Jason Creighton wrote:
> > > 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?
> 
> Oh, right. "refresh" raises the focused window. So it works, but by
> accident.
> 
> Maybe that's not a fair way of putting it. As xmonad is currently
> written, the focused window has to be raised because we don't move the
> other windows out of the way. So while it seems kludgey to me, it will
> work, as you have noted. But it also seems distasteful to not be able
> to, for example, check all the normal properties (non-overlapping
> windows among them, I believe) with QC. So my opinion is that it would
> be better to pass in the focused window, as you propose below.

I agree.  It'll be cleaner to pass in the focussed window.  It's also
helpful for certain sorts of layouts I can imagine, where the focussed
window is treated specially (e.g. if I had a keybinding to make the
focussed window a bit wider).

> > > 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.
> 
> Hmm. What advantage does using classes have over just having a data type
> with multiple constructors, and have layout functions ignore messages
> (ie, constructors) they don't know about?

The advantage is that new layouts can be developed that desire new sorts of
messages without modifying all the other layouts.  You could also acheive
this by having a standardized name for the message datatype and adding an
additional config file that is imported into Operations, but that seems
kludgey.  Or if ghc supported mutually recursive modules, that could also
make it work.  But the class approach seems cleanest to me--I don't like
the mutually recursive approach, as it means that a change in Config could
cause Operations to fail to compile, which doesn't seem like a friendly
interface for people who just want to change their key bindings.
-- 
David Roundy
http://www.darcs.net