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 _______________________________________________ [email protected] mailing list http://wmii.de/cgi-bin/mailman/listinfo/wmii
