Re: [wmii] snap: 20060309

From: Uriel <>
Date: Thu, 9 Mar 2006 16:39:48 +0100

On 3/9/06, Anselm R. Garbe <> wrote:
> Hi there,
> things get more and more stable and usable, thus it is time once
> again to release a new snapshot which can be downloaded from:
> (59kB)
> This snapshot contains many changes:
> - Fixed several crashing bugs (much more stable than yesterday's
> snap)
> - Implemented /ws/sel/sel/class (/client/X/class) file which
> contains the class:instance string of the specific client
> - tags which are prefixed with the '~' character have the effect
> that the specific client is forced to be floating
> - Transient windows have this prefix now
> - Implemented /def/class namespace which can be used to
> predefine specific tags for special class:instance definitions
> of clients, ie
> wmiir create /def/class/'Gimp:*'
> echo -n '~3' | wmiir write /def/class/'Gimp:*'
> which results that all Gimp windows will appear floating in
> tag 3.
> - If you don't supply any tag after the floating character (~),
> then an entry will only force that the specific class:instance
> is attached as floating, regardless the client, ie:
> wmiir create /def/class/Xterm:xterm
> echo -n '~' | wmiir write /def/class/Xterm:xterm
> which results that all xterms will be attached as floating and
> inherit the tag of the specific ws (or /def/tag if none
> exists).
> - If you apply a tag like '~1 2' to a client this will force
> wmii to show it floating in tag "1" and normal in tag "2"
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".

Probably in the future we want to extend this to be able to match
against anything
xprop(1) can show (BTW, might be nice to export all those attributes
in a file in the client dir); also we might need syntax not just to
set the tag but to add and remove tags. Here is an example of the kind
of language I'm thinking of, this is probably over-engineered and at
the same time might lack some of the needed features, but show the
kind of language and the heavy AWK inspiration:

/Gimp:*/ -> graphics
/Gecko:*/ -> +web
WM_NAME ~ "BBC NEWS" -> +news -web
WM_CLIENT_MACHINE ~ "^satori" -> +satori

~ means regxp matching (not sure yet if we will need other kinds of
operators, probably ! negation will be needed), /foo:bar/ is a
shortcut to do globing-style matching against the class:instance. +tag
adds that tag to the window, -tag removes that tag from the window, an
unqualified tag name replaces all tags for that window. The list is
iterated top to bottom and the matching patterns are applied to the
list of tags for this window, which starts with the inherited tag from
the "current tag".

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.

Received on Thu Mar 09 2006 - 16:40:00 UTC

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