compiz - Feb 2007 - window matching interface and the new match option

There's now an extensible window matching interface in head.

Initial commit message:

    Add extensible match interface. Match objects can be used for
    window matching but other objects than windows will likely be
    supported sometime soon. A match object contains a boolean tree
    of expressions and each expression can be implemented by a
    different plugin. The core interface only provides window type
    matching.
    
    Plugins can provide any kind of matching by wrapping
    the matchInitExp display function. When doing so they
    are responsible for calling the matchExpHandlerChange
    function when their ability to evaluate expressions
    changed (e.g. when being activated or deactivated).
    They should also call the matchPropertyChanged function
    when a window property that might affect evaluation of
    an expression changed.

Any kind of matching can be done with these match objects. Core
currently support simple things like window type, window state, window
ID and I'll probably add a bunch more as I find them useful. If you have
any window properties that you find useful for matching, please let me
know and I'll consider adding them. Whether they get added to the core
or not doesn't matter as you can always put the matching in a plugin. 

I've added a regex plugin that provides regular expression matching for
window title and other string properties. It probably needs some more
work for multi-language support but it's a good example for how to write
a plugin that extents the match interface.

Plugins can use match objects for general window matching but the most
common case is probably things like the old window type option where
what windows an effect or action should apply to is made configurable. A
new match option type exists for this and it's very easy to use. I've
converted all plugins in the master branch to use the new match option
instead of the old window type option. Look at the changes to figure out
how to convert other plugins. In general you can just replace window
type options with match options but you should keep in mind that any
kind of matching can be done by these new match options so you should
avoid using them in performance critical code, like each time a window
is painted.

Here's a few use cases that you can try out today if you just pull the
latest bits from the master branch.

1. Simple window matching for a specific action. I've added a
focus_prevention_match option which allow you to specify which windows
focus prevention should apply to. E.g. when having the regex plugin
loaded you can set the option to something like this:

"(!class=Gecko | title=*Pref*) & !class=*terminal*"

2. Keep a consistent state which depend on some window properties. The
blur plugin now include an option which allow you to specify for which
windows destination blur should be automatically enabled when no window
property is set. If you set that option to:

"title=*terminal*"

the plugin will need to know when the title changes to something that
might make that match no longer true or the other way around. The
matchWindowPropertyChanged function exists for that purpose and by
wrapping that function you'll know when some window property that might
affect the window matching you're doing have changed and you can then
re-valuate the matching for that window. 

3. Can be use to dynamically specific which windows an action should
apply to. I've updated the initiate actions in the scale plugin so it's
possible to provide a match option as argument to any one of them. This
means that an external source can initiate scale mode for a specific set
of windows. E.g. by using the dbus plugin you can do this

dbus-send --type=method_call --dest=org.freedesktop.compiz
/org/freedesktop/compiz/scale/allscreens/initiate
org.freedesktop.compiz.activate string:'root' int32:`xwininfo -root |
grep id: | awk '{ print $4 }'` string:'match'
string:'class=Gnome-terminal'

to initiate scale mode only for gnome-terminal windows. You can use
something like "string:'xid=0xc1cd78 | xid=0xc200a0 |
xid=0xc2100b'"
instead if you want to specify the exact windows.


We'll probably find more use cases as plugins which provide more
interesting matching emerge. I can imagine that matching based on window
updates per minute or pixels changed per second could be useful and
wouldn't be hard to implement.

If you have any questions related to this or if you have problem
converting some plugin to use the new match option, please let me know.

- David

David Reveman wrote:
> If you have
> any window properties that you find useful for matching, please let me
> know and I'll consider adding them. Whether they get added to the core
> or not doesn't matter as you can always put the matching in a plugin. 
>   
Just a couple.  PID and/or process name and window max/min_height/width
would be useful, also maybe paint values.  It could either use
min max, or the match format could be extended to support
 >, < etc

It would also be very useful if the match string could include a
value as well.  This would mean that plugins like blur could
have a list of matches with values and it could apply different
types of blur to different types of windows.  eg.  It could use
4xBilinear for any window which is wider than 500 px like this

min_width=500 =4xBilinear

The core could always parse this as a string and then the plugin
can convert it to the type that it requires.  I think it would be useful
for almost all the plugins that use window matching (fade could have
different fade speeds for different window types).

On Tuesday 27 February 2007 01:43:32 Mike Dransfield
wrote:
> It would also be very useful if the match string could include a
> value as well.  This would mean that plugins like blur could
> have a list of matches with values and it could apply different
> types of blur to different types of windows.  eg.  It could use
> 4xBilinear for any window which is wider than 500 px like this
>
> min_width=500 =4xBilinear
>
> The core could always parse this as a string and then the plugin
> can convert it to the type that it requires.  I think it would be useful
> for almost all the plugins that use window matching (fade could have
> different fade speeds for different window types).
I agree with you, we need this...

Another question, do we need a state plugin?
blur, switcher, ... now use "window matching"  to enable/disable
effect. With
your proposition, we should be able to specify blur type.

So, with window matching, bs plugin should set brightness/saturation, place 
plugin should set window position/stacking, decoration plugin should set 
decorations, ...

So my question is: Should we have a state plugin or should we have a per 
plugin window matching? I know it will increase plugin size, but i think it 
should make compiz configuration much more consistent (instead of having some 
matching in plugins and some matching in state)

Another thing, for now, opacity increase/decrease is in core, i think it 
should go in bs plugin (rename it bso plugin).

Cedric

On Tuesday 27 February 2007 15:03:02 Mike Dransfield
wrote:
>  It just sets the atoms
> which core responds to, so it is just a hack.
It's exactly what is doing compiz core with opacity...

Look at increaseSaturation() and inceaseOpacity(), the code is the same... So 
bs code comes from compiz core, i see no reason to have this in core...

Cedric

David Reveman wrote:
> If you have any questions related to this or if you have problem
> converting some plugin to use the new match option, please let me know.
>
>   
I have been doing some testing with the blur plugin.

Here is my match string for alpha_blur

class=Konsole & !state=maxvert

This should remove the blur when it maximizes, but it
doesn't.  I have tried it with other state matches and other
plugins with the same effect.  There is no matchPropertyChanged
notification when a window changes state.