What you described is called "named workspaces", and it *SUCKS*, that is what ion has(had?), and it totally fucking sucks. The whole point of tags is that you can attach as many tags as you like to every object, and then pick your current selection from the list of tags. The whole point is to have multiple _views_ that are _overlapping_ sets. So that your "code" view can contain windows that are also running on another host and are accordingly tagged, as someone pointed out, or that a web browser can be tagged as "web" and as "documentation", or whatever.
What is totally retarded is to allow concurrent selection of more than one current tag at the same time, because it makes the current state much more confusing, and provides zero extra functionality that can't be archived by just adding an extra tag to the union of the groups you want to tag. The problem I suspect is that you have yet to provide any sane mechanism to easily tag windows on the fly, so no wonder it is hard to use. As usual you discard ideas before properly putting them into practice, and make judgements based on incomplete data and your own braindamaged personal use patterns. And I can't be bothered to read the code anymore, because it make me ill, but I bet that those hundreds of lines of code you talk about are totally gratuitous fluff, multiple concurrent tag selection certainly needs much more code to merge the sets dynamically and to keep the state not only per tag, but per set of tags. Now shout and scream about how wrong I am, I just don't care anymore because you keep arguing, and keep being proved wrong, and you never learn. uriel P.S.: I think that the next time I hear a totally idiotic argument justified by some irrational statement about lines of code I will just reformat my last lunix box with Plan 9 and forget all this idioticy. There is nothing I hate more than someone doing braindamaged abominations in the name of a good cause. On 4/7/06, Anselm R. Garbe <[EMAIL PROTECTED]> wrote: > Hi there, > > I used the recent version for at least several weeks and noticed > that I never need any client containing more than a single tag. > > But handling stuff like 1+2+foobar in .../<client>/tags file, > means several overhead (for those who are familiar with the wmii > source code, the Frame struct has been invented esp. for this > reason). In other words, this overhead means several hundred > lines of code. > > Thus I propose, to only allow a tag per client. This would > result in something like a (it is really a superset if you think > further about it) workspace-alike approach, though it is more > simple than workspace handling, and we got already all > mechanisms to run specific classes/instances of clients in > specific tags. The overall concept won't change, except > disallowing tagging a client with more than one tag, and the > removal of * tag. > > I know that this is somewhat like the ws-approach, but I see no > need for the special complexity... > > Any concerns removing that? > > Regards, > -- > Anselm R. Garbe ><>< www.ebrag.de ><>< GPG key: 0D73F361 > > _______________________________________________ > [email protected] mailing list > http://wmii.de/cgi-bin/mailman/listinfo/wmii >
_______________________________________________ [email protected] mailing list http://wmii.de/cgi-bin/mailman/listinfo/wmii
