[Xmonad] darcs patch: make workspace tag not need to be a Num.

[Stefan O'Rear]

On Wed, Jun 13, 2007 at 05:58:31PM -0700, David Roundy wrote:
> On Wed, Jun 13, 2007 at 05:03:32PM -0700, Stefan O'Rear wrote:
> > On Wed, Jun 13, 2007 at 04:57:41PM -0700, David Roundy wrote:
> > > On Wed, Jun 13, 2007 at 03:15:03PM -0700, Stefan O'Rear wrote:
> > > > On Wed, Jun 13, 2007 at 09:43:39AM -0500, Spencer Janssen wrote:
> > > > > > This seems particularly relevant as dons is talking about creating a
> > > > > > Stack for the float layer (which makes lots of sense to me), and I'll
> > > > > > be voting for allowing custom layouts to the float layer: part of my
> > > > > > grand scheme to make the float layer an equal citizen with other
> > > > > > layout systems, but also useful for people who want tabs on their
> > > > > > windows so they can see titles and drag them around with the use of
> > > > > > only one hand.
> > > > > 
> > > > > Yes, this is a good idea.  After all, a floating layout is just a
> > > > > layout that happens to listen to windows requested sizes.
> > > > 
> > > > Sadly, xmonad's current floating layer is NOT such a floating layout
> > > > because it is stateful - it allows you to resize windows.
> > > > 
> > > > Layout-level state is not an option because then the windows would
> > > > forget their size when moved between workspaces.
> > > > 
> > > > The only reasonable approach I can think of (_XMONAD_USER_SIZE
> > > > properties) is probably unacceptable because it is deeply untyped.
> > > 
> > > That's something I've wondered about.  Why do we need to store the size and
> > > position, doesn't X store the size of windows, even when you've hidden
> > > them? I imagine that it has to do with Xinerama, and have speculated as to
> > > solutions, but would rather not bore you with my speculations without
> > > knowing why exactly we feel the need to store those RationalRects.
> > 
> > It definitely has nothing to do with Xinerama.  Probably it has a lot to
> > do with the fact that we used to hide windows by moving them offscreen;
> > this needs to be re-evaluated.  As such I'm CC-ing the deciders.
> 
> Ah, then an easy solution would seem to be to move windows offscreen by a
> fixed distance (chosen perhaps to be larger than any reasonable viewable
> area, or perhaps chosen at runtime to be larger than the actual screen
> area).
> 
> But why is it that we can't just unmap the windows? (possibly displaying my
> ignorance...)

Indeed. :)  I used past tense, because unmapping is what we do now.

As of:

Sun Jun  3 21:23:43 PDT 2007  Stefan O'Rear <stefanor at cox.net>
  * Set WM_STATE, iconify invisible windows (+9 loc)
  Note that this breaks compatibility with certain programs described as
  "obsolete" in the ICCCM (1994).  See the command above the UnmapEvent handler
  for details.

Stefan