[Xmonad] darcs patch: Added LayoutMessages

[David Roundy]

NOTE: I changed my opinion as I wrote this response, but haven't gone back
to rewrite the whole response, so understand that it's more of a story than
a coherent exposition of a well-thought-out opinion.

On Mon, Sep 24, 2007 at 05:05:26PM +0200, Andrea Rossato wrote:
> On Mon, Sep 24, 2007 at 07:46:29AM -0700, David Roundy wrote:
> > On Mon, Sep 24, 2007 at 04:20:32PM +0200, Andrea Rossato wrote:
> > > Hi,
> > > 
> > > as we said yestarday this is my proposal for a more sophisticated
> > > layour message system.
> > > 
> > > Basically: UnDoLayouts is used for refreshes, LayoutSwitch wfor
> > > notifying a layout change, and NonVisible when a layout is a workspace
> > > not visible anymore.
> > 
> > I don't see why we need so many messages.  It seems like UnDoLayouts should
> > now be unused, and NonVisible should be treated the same as LayoutSwitch.
> > Do you have a use case where these should be treated differently?
> 
> Two messages would actually be fine for me. The problem is that I
> would like to know when I must hide and when I must free the
> resources.

And I presume you want to free the resources when the layout is changed? To
me, it seems that you'd want to treat the two the same way.  When a
workspace is hidden, there's no guarantee it'll ever be shown again, and
I'd rather free resources at that time.

Alternatively, perhaps you'd rather have a DestroyLayout message? Then we'd
only free resources when we really need to, and temporarily switching to
fullscreen mode wouldn't involve allocation/deallocation of resources.

> I also have the Read instance problem, which I did not study carefully
> yet. If I want to cache the fontStruct/Set together with the window
> ids, I would like to know when XMonad is going to be restarted. The
> cache is done in a Maybe type and I would like to free all the
> resources and return a Tabbed Nothing TConf, which could be read (am I
> guessing right here?).

It seems like this would be trivially solvable by broadcasting a
DestroyLayout message prior to calling show on the StackSet.

> > However, it might be nice to have a Focus/NonFocus message.  This would
> > allow WorkspaceDir to work properly with multiple screens.  A related
> > (and perhaps better) possibility would be to create a different method in
> > Layout for drawing focussed stacks versus unfocussed stacks.  The default,
> > of course, would be for both to be drawn the same.
> 
> Neither solves the release/hide resources issue, btw.

Right.

> > class (Show (layout a), Read (layout a)) => Layout layout a where
> >     doLayout :: layout a -> Rectangle -> Stack a -> X ([(a, Rectangle)], Maybe (layout a))
> >     doFocusLayout :: layout a -> Rectangle -> Stack a -> X ([(a, Rectangle)], Maybe (layout a))
> >     doFocusLayout = doLayout
> >     modifyLayout :: layout a -> SomeMessage -> X (Maybe (layout a))
> >     modifyLayout _ _ = return Nothing
> > 
> > Actually, I think this is exactly how I'd like to handle focus.
> > 
> > But I really don't see a use case for NonVisible vs UnDoLayouts vs
> > LayoutSwitch, and am not keen on sending and defining messages without an
> > envisioned use case.  If some day someone comes up with an idea that
> > depends on distinct NonVisible and LayoutSwitch messages, we could easily
> > split them apart, but until then, I'd prefer to have a single message sent.
> > At a minimum, I'd vote for eliminating UnDoLayouts.
> 
> In which case how would you suggest to handle the specific problem of
> Tabbed?

Personally, I'd vote for always releasing resources when the workspace is
either NonVisible or when it's only the Layout that is hidden.  This seems
simplest, and I'm not convinced that simply hiding the tab windows would
give us much of a performance gain.  But if you want the performance gain
of hiding tab windows, then it seems like you may as well have that
performance gain when switching to Full and back again, in which case you'd
always hide except we might want a DestroyLayout, or maybe we should call
it a CleanupLayout or FreeResources message that really would ask for any
resources to actually be freed.  But the FreeResources message would be
sent either if the layout is being destroyed, or if the Workspace is being
destroyed, or if xmonad is about to quit.  So calling FreeResources
LayoutSwitch seems a bit of a misnomer (or calling FreeResources NonVisible
would also be a misnomer, if you were thinking to release the windows when
the workspace became nonvisible).

So you've convinced me that two messages would be a Good Thing, but I'd
vote for a Hide and a ReleaseResources message, with the latter being sent
if we're going to discard a Layout (possibly because we're going to discard
a Workspace) or before we exit (in which case it should always be called
before we show the Layout).

Note that in any case NonVisible must be treated as a superset of
LayoutSwitch, since once a LayoutSwitch is received, NonVisible messages
will *not* be received.  i.e. anything that must be done in response to
NonVisible must also be done in response to LayoutSwitch.
-- 
David Roundy
Department of Physics
Oregon State University