Re: [wmii] multitags

From: Anselm R. Garbe <garbeam_AT_wmii.de>
Date: Mon, 10 Apr 2006 13:05:34 +0200

On Mon, Apr 10, 2006 at 10:57:18AM +0200, Steffen Liebergeld wrote:
> 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.

I already told so.

> 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).

There is a retag command in hg tip, which can be used to apply
/def/rules to all existing(!) clients.

> 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.

No sorry, this is 9P.

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

First of all complex regexes are not necessary, POSIX regexps
are totally sufficient (they are supported). Second the current
rule matching mechanism does not only matches the class name, it
even matches the client's title.

Regards,

-- 
 Anselm R. Garbe  ><><  www.ebrag.de  ><><  GPG key: 0D73F361
Received on Mon Apr 10 2006 - 13:05:34 UTC

This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 16:02:08 UTC