Re: [wmii] multitags

On Fri, 7 Apr 2006 20:22:56 +0200, "Anselm R. Garbe" <garbeam_AT_wmii.de> said:
> 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?

Yes. Multitags are a very powerful way to compose views. So I ask you
to keep them at least until the release of wmii-3. We already lost
lots of users because of the many changes, which happened even after
the proposed release-dates.

So *please* keep them.

For wmii-4, I propose you to invent a new strategy to compose
views. It should be possible to match Window Names or Classes in a
self-composed view. I want to be able to say something like every
window which matches the regex /^emacs/ig should be in a view
emacs[1]. It should nevertheless be in the view belonging to its tags
(e.g. by appending the new emacs-tag to its tags). I know this is
already possible with the current wmii, but the implementation would
be arkward: search through all /clients/ and parse their names and
classes file. Thats very rough because there is no good way to search
through the filesystem (which will change with fuse).

And: when speaking about minimal code, you have to consider removing
all the silly info wmiir outputs. Why have those files times sizes,
times and even an owner? Currently, as the only use would be for a
local user, it should be assumed that he knows who he is, and wmiir
can savely omit that stupid output. It would be much easier to parse
if would only output the file and dir names.

Sorry when I was a bit rough today, but I am really annoyed by all
those nifty ideas streaming in, which would break the concepts again
and again. Keep wmii-3 stable, and release it. Save your creativity
for wmii-4.

Just for the note: I really like wmii-3 and I love that it has an
active community.

Footnotes:
 [1] Current rules-file only matches Classes and doesn't allow complex
     regexes.

-- 
Microsoft is simply one example of a proprietary software developer, a
software developer that tries to subjugate users to keep them divided
and helpless. -- Richard M. Stallman