On 3/9/06, Anselm R. Garbe <[EMAIL PROTECTED]> 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: > > http://wmii.de/snaps/wmii-20060309.tar.gz (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. uriel
_______________________________________________ [email protected] mailing list http://wmii.de/cgi-bin/mailman/listinfo/wmii
