[compiz] window matching interface and the new match option

[David Reveman]

On Tue, 2007-02-27 at 00:43 +0000, Mike Dransfield wrote:
> 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

PID can be in the core. Process name, host name.. and everything else
you can think of that are strings should be in the regex plugin.

Window dimensions would be useful. '>', '<', '=' can be used without any
changes to match interface as those things are up to the expression
handler to parse and there's nothing that prevents that right now.

If you or anyone else feel like implementing a few of these please do
so.

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

I don't think we want this in the match option. What you want is a list
of (match, int) pairs and that can be created right now by having two
list options. However, I've been waiting for a good reason to add a pair
option type and this seems like the perfect case.

I'm sure that people would want a window-opacity-match option which
controls opacity of windows without the opacity property set. This would
be a list of (match, float) pairs.

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

Yes, I can imagine that there's a lot of cases where this can be useful.

Do you agree that adding a pair option type is the best way do this? In
that case I'll go ahead and add it.

- David