[Xmonad] eliminating Workspace?

[David Roundy]

On Mon, Jun 18, 2007 at 03:37:20PM -0500, Spencer Janssen wrote:
> On Sat, 16 Jun 2007 13:26:25 -0700
> David Roundy <droundy at darcs.net> wrote:
> > I have an idea that I'd rather run by folks before
> > implementing--particularly as my tag-as-not-Num patches haven't been
> > accepted.  I'd like to add a tag field to Stack
> > 
> > data Stack i a = Stack { data   :: !i        -- name of this stack
> >                        , focus  :: !a        -- focused thing in this
> > set , up     :: [a]       -- clowns to the left
> >                        , down   :: [a] }     -- jokers to the right
> >     deriving (Show, Read, Eq)
> > 
> > and thus eliminate the Workspace data type.
> 
> This means that all stack manipulating functions need to keep track of
> this tag, a bit of a pain in my opinion.

I'd point out that we have to keep track of this tag anyhow, so we haven't
complicated anything (with one exception, which you point out).  And since
we've reduced by a factor of three the number of data structures, I suspect
we'll gain significantly in code simplicity, since you need one-third as
many manipulation functions.

> > The goal of this would be to also eliminate the Screen and StackSet
> > types, replacing them with something like:
> > 
> > type Workspace i a = Either i (Stack i a)
> 
> This is where the tag becomes painful :).  (i, Maybe (Stack a)) is much
> nicer in my opinion (or an equivalent named record).

Yes, this is indeed ugly.  It'd be far prettier if we could avoid allowing
empty workspaces and create them on demand.  But alas, users should be able
expect to not lose a carefuly configured layout just because they closed
all the windows in that workspace.  Still, it'd be very pretty to only
allow non-empty workspaces!  :)

> > type StackSet i a sid = Stack (M.Map a RationalRect)
> 
> It looks like you missed something in the definition of StackSet.
> Perhaps you mean 'Stack (Map a Rect) (Workspace i a)'?

Right.

> > This data structure includes a bit more information than our current
> > StackSet, in that it associates each Workspace with a given Screen.
> > This was recently requested as an option, so I think this is a good
> > thing.  Note that this doesn't require a change of behavior, is just
> > make the existing behavior slightly more complicated, and the
> > behavior where Workspaces are pinned associated with screens
> > possible.  I only have one screen, but I can certainly imagine that
> > if I had one large and one small screen, I might like to be able to
> > designate certain Workspaces for either one or the other.
> 
> I have a gut feeling that this will significantly complicate a few
> core functions.  'view' (and the new proposed version, greedyView)
> seem to be a bit painful with this proposal.  'rescreen' will also
> become more complicated.

True, view is made more complicated, but not overly so.  I don't see why
rescreen would become more complicated, but won't disagree.

> > Anyhow, comments, suggestions and estimates as to whether such a
> > drastic change would be accepted will all be appreciated.
> 
> There is a fundamental tension here: the original authors perceive
> StackSet as a structure indexed by workspace ids, but you'd like to use
> it as a rotational structure.  [...]

That's true.  I greatly prefer the simplicity of rotating through
workspaces and if I had more than one screen, I'm sure I'd want to rotate
through those.  I suppose you core folks only allow rotation through
windows because it's too hard to assocate an index with each window.

The other major consideration is that of symmetry.  It feels like xmonad
core is going the way of ion3, which I'd prefer to avoid:  we've got four
levels already of distinct data types, and with dons' idea of using a stack
for the float layer (of which I totally approve) we'll have even more
complexity.  I *very* much like the idea of using the same data structure
and the same to get the same effect.

I guess another factor is the fact you seem to think of the screen and
workspace levels as being static, while I'd much prefer a dynamic
configuration--particularly at the workspace level.  Which means inserting
and deleting workspaces becomes a meaningful concept, and the same sorts of
issues come up that have already been dealt with on the window level: where
does focus go when you delete a workspace? Where does it go if a screen
disappears (which I understand could happen with xrandr?)? I think it'll be
nicer to have a more unified picture.  And while this code simplifies some
functions and complicates others, it doesn't impose any change in
behavior.

> The current implementation is well optimized for the operations supported
> by the core -- I'm reluctant to complicate core operations to simplify
> operations in a contrib module.

By well-optimized, do you mean for speed or simplicity of code? I hardly
believe that it is really well-optimized for speed.  When the total number
of workspaces is limited to 10 (yes, in theory it could be increased, but
not by much without making the UI cumbersome), an O(log(n)) code is
unlikely to beat a O(n) code, at least not by much.

In any case, my hope would be to simplify the core code, not to complicate
it.  If the core developers don't believe this could be a simplification,
then I won't make the attempt.
-- 
David Roundy
Department of Physics
Oregon State University