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 <garbeam_AT_wmii.de> 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
>
> _______________________________________________
> wmii_AT_wmii.de mailing list
> http://wmii.de/cgi-bin/mailman/listinfo/wmii
>
Received on Sun Apr 09 2006 - 23:41:31 UTC
This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 16:02:02 UTC