Re: [wmii] Automatic destruction of views

From: Sander van Dijk <a.h.vandijk_AT_gmail.com>
Date: Fri, 21 Apr 2006 16:47:55 +0200

On 4/21/06, Anselm R. Garbe <garbeam_AT_wmii.de> wrote:
> On Fri, Apr 21, 2006 at 03:52:47PM +0200, Sander van Dijk wrote:
> > Being able to 'stay' on an empty view, but not being able to select a
> > random empty view, is inconsistent. I'm firmly against removing the
> > autodestroying of views, but if it was ever to happen, doing
> > xwrite /ctl view some_nonexisting_tag
> > should put you in the same situation as removing the last client of a
> > tag, for consistency's sake.
>
> Yes, and that might be a side-effect which could be advantageous
> as well. I heared many users asking for a way to run specific
> rule-less clients in a specific view. Selecting an non-existent
> view and then running a bunch of clients would be a simple
> solution. Though, I'll need to think about it further.

Well, if one can both stay on and select empty views, but they are
destroyed when they are left, then we would still have a consistent
way of dealing with empty views (they can be selected, but vaporize
into thin air when they aren't). It might be worth considering, but
we'll have to look out for cornercases:
- When clients are started in xinitrc, they initially get the fallback
'nil' tag.
- then, when the wmiirc rules kick in, they are retagged to '1'.
- because this makes the 'nil' view empty, it is destroyed, and view
'1' is selected.
However, if empty views are allowed to keep focus, then what should
happen here? Should the empty 'nil' view keep focus, or should it be
treated specially and be the single one view the _is_ destroyed when
it's empty but still focussed? Should it also be destroyed when it's
empty and focussed, but there are no other views?

I'm not sure if it's a good idea to go and change the autodest.
behavior so shortly before release...

Greetings, Sander.
Received on Fri Apr 21 2006 - 16:47:57 UTC

This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 16:03:09 UTC