Re: [wmii] snap: 20060309

From: Anselm R. Garbe <garbeam_AT_wmii.de>
Date: Thu, 9 Mar 2006 17:00:05 +0100

On Thu, Mar 09, 2006 at 04:39:48PM +0100, Uriel wrote:
> This "calss" system seems way too complicated (I don't think I even
> understand it)
>
> All that is needed is a single file that contains one rule per line:
> /pattern/ -> tag list
>
> Inside /pattern/ you could have either regexps or shell-style globing. Only
> think that should be taken care is that it should be possible to match other
> attributes than "class:instance".

I like your idea, except that I hope you don't mean to have such
file in wmii's virtual filesystem, but define that stuff in
wmiirc instead and having an event whenever a new window
appears, that you can match your rules with awk from wmiirc and
writing the specific tags to /clients/<id>/tags.

This would allow easy xprops integration. The event
might only provide the window id which can be used as argument
for xprop, ie: xprop -id <id> (that is no big deal and can be
easily supplied as event argument). Instead of using the global
array indexes as directory names in /clients/ we could use
the window id instead, ie /clients/0x600020/...
(actually it is only important to have the indexes in /ws
namespace, but knowing the wmii indexes in /clients is pretty
pointless). Assumed you receive some event (MC = manage client)
like

MC 0x600020

in wmiirc you could run xprops -id 0x600020, match whatever you
like and do

xwrite /clients/0x600020/tags +new -web

for example. This would remove all this complexity from wmii and
prevent us inventing the wheel of a matching language and allow
the user much flexibility (we only have to take care about
tags).

> /Gimp:*/ -> graphics
> /Gecko:*/ -> +web

Those should be checked against WM_CLASS, ie

WM_CLASS(STRING) = "xterm", "XTerm"

(output for xterm)

> Anyway, this is just a rough idea, probably will need many iterations
> of polishing, we should probably start with the simplest form of
> /foo:bar*/ -> tag list
> (without tag-qualifiers) and then extend the language as we find need
> more fine grained expressions.

I'd like to get rid of the /def/class handling within the WM, we
could safe a lot of code without it (approx. 200 lines).

Regards,

-- 
 Anselm R. Garbe  ><><  www.ebrag.de  ><><  GPG key: 0D73F361
Received on Thu Mar 09 2006 - 17:00:05 UTC

This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 16:00:53 UTC