Re: [wmii] Stacks

On Fri, Mar 03, 2006 at 03:10:54AM +0100, Uriel wrote:
> > Tagging windows with arbitrary tags sounds pretty painful to me.
> > It is easy to press or invoke a tag sending a window to a
> > specific page (that is like a tag) and you don't have to think
> > about how you call the tag, because a page is associated with a
> > number.
> You would usually select from a predefined set of tags, and you probably
> could asign default tags based on regexp matching of the window id
> string, so I don't
> think this is necessarily a big problem, you could then associate Alt+1 with
> tag-ws "email" Alt+2 with tag-ws "dev" and so on, and one window could
> show up in more than one virtual ws (a ws would be just a collection
> of all clients that have a certain tag.)
>
> New windows could inherit the tag of the current ws by default.

Well, sounds like an page id <-> tag mapping, no big deal. But
we can think about it after wmii-3 if it would make sense.

> [BTW, once more, why the hell we have "pages" and not "workspaces"?
> it's confusing and senseless]

I'm open to change it to something else. The original reason I
called them 'pages' is because the tiny tool which shows your
'workspaces' in WIMPish environments is called 'pager' and not
'workspacer'. Also the term 'workspace' is somewhat misleading
because it implies some static understanding of managing windows
in different places. If we're going to adapt you ideas after
wmii-3 and make such 'pages' something like dynamic groups of
referenced clients the 'page' term would also be rather static.
Dunno of 'container', 'layout' or 'vscreen' would be better
terms. Would be interesting to hear comments from native
speakers about this question.

> > With this in mind, we already got 'dynamic pages' in my eyes,
> > though I considered a completely different idea, namely to
> > destroy empty pages automatically without the exception of page
> > 0. But on the other hand it would force the dynamic concept
> > completely on a page level and Machnus for example won't be able
> > to keep up his static environment where a specific page contains
> > specific clients for a special task ...
> I don't like this, numbered workspaces should not be dynamic, because
> there is no
> nice way to select among them except by associating them with numbers,
> if the associations change on the fly, it can be rather annoying.

Agreed.

> At first I thought it was crazy, and it was mostly a joke, but I'm
> starting to like the idea of tag-workspaces more and more, they could
> easily implement the current behaviour (just have tags as numbers) and
> they could be generalized to handle Machnus style of working too(just
> associate a numeric (or mnemonic) keybinding with each of the tag-ws.
> This would have the advantage of allowing to very easily show a client
> in two different ws. You could have a 'nil' to collect all clients
> that have no tags(but this would be rare, as new windows would at
> least by default inherit the tag(s) of the current ws... oh, yes, a
> single ws could have more than one tag, so for example you could have
> irc+email ws.

Well, as I told, in the end it is a minor change, because you
would just keep arbitrary references to globally available
clients in such 'workspaces', 'tag-groups' or how you might want
to call them. The interesting point about it is, that you could
drop the sendto pattern completely (except for rearranging in
columns which needs some function to move a client into another
column). The first step in this direction is already with the
removal of the detach/attach usage pattern.

> Drawbacks I can think of is that cycling through the list of tag-ws
> becomes less clearly defined, but then that always was a rather lousy
> way to move around if you had too many ws.
> Anyway, maybe I have gone completely insane.

I'm not sure, but when thinking about your idea it sounds
more and more interesting. In the end it just allows things like
sticky windows in a very natural way, because tagged clients may
occur in different pages...

Regards,

-- 
 Anselm R. Garbe  ><><  www.ebrag.de  ><><  GPG key: 0D73F361