Re: [compiz] window matching interface and the new match option

2007-03-03 Thread Mike Dransfield

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.

___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz


Re: [compiz] window matching interface and the new match option

2007-02-28 Thread David Reveman
On Tue, 2007-02-27 at 16:39 +, Mike Dransfield wrote:
 David Reveman wrote:
 
  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.

 
 I will have a look at PID and window size matching using greater
 than and less than, the others are not so important now.
 
 Also do you think it would be OK to add an override redirect match?
 It would make it possible to work around a few toolkit bugs (ie. the 
 mozilla
 menu problem)
 
 
  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.
 
 It sounds good :)

I had a look at this and I'd like to wait with adding a pair option type
until we've moved the ini plugin and dbus plugin updates into master.

I've added general window opacity matching as two list options for now.

- David

___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz


Re: [compiz] window matching interface and the new match option

2007-02-27 Thread Mike Dransfield

Bellegarde Cedric wrote:

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.
  


I think we will still need a state plugin, maybe other plugins
could take care of some things like initial viewport, but there
are some things which we would want to do which would not
fit into any plugin.

If you look at KDE's window specific settings then look at the tabs
labeled workarounds and preferences, you can see all the things
that state can still take care of.  They are basically hacks to
windows a lot like what state has now.  I am only using KDE as
an example because I know it is very comprehensive (and I have it
here), I have no idea about metacity.

State might eventually be able to fix certain toolkit bugs with
a config line rather than having to code the workarounds into
either core or the plugins.

If we had the ability to match override redirect windows then
we could fix the mozilla menu bug without code.

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


Or you could call it the obs plugin ;)

I have been giving this one a lot of thought and this is my
conclusion.

The bso plugin should not exist because it does not actually
do the work of changing the paint values.  It just sets the atoms
which core responds to, so it is just a hack.

I personally think the actions for bs should be in core, but on
the other hand, how useful would they be?  If they are not used
by most people then to them it is just bloat.  I think changing the
opacity is very common but not brightness or saturation.



___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz


Re: [compiz] window matching interface and the new match option

2007-02-27 Thread Danny Baumann
Hi,

 Or you could call it the obs plugin ;)

Yes, I did exactly that in Beryl ;)

 The bso plugin should not exist because it does not actually
 do the work of changing the paint values.  It just sets the atoms
 which core responds to, so it is just a hack.

I disagree. obs (as well as bs before) changes both paint values and the
atoms.
BTW, Beryl's obs plugin is public domain, so it could be in Compiz as
well :)

 I personally think the actions for bs should be in core, but on
 the other hand, how useful would they be?  If they are not used
 by most people then to them it is just bloat.  I think changing the
 opacity is very common but not brightness or saturation.

Well, IMO opacity shouldn't be in core, too. Opacity changing isn't
really a core compentence of a window manager, even if it is a composite
one. Having all paint modifier changing in one plugin is the solution
that makes most sense for me.

Regards,

Danny

___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz


Re: [compiz] window matching interface and the new match option

2007-02-27 Thread David Reveman
On Tue, 2007-02-27 at 00:43 +, 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

___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz


Re: [compiz] window matching interface and the new match option

2007-02-27 Thread Bellegarde 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
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz


Re: [compiz] window matching interface and the new match option

2007-02-27 Thread Mike Dransfield

Bellegarde Cedric wrote:

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


  


I think that part is the candidate to be removed into a plugin
but I do not think it would not bring much benefit.

For users who do not manually modify brightness and saturation,
it would actually be a larger overhead.

My point is that most of the window painting stuff is handled by
core, so to really have an opacity/brightness/saturation plugin, you
should remove either all the functionality or none of it.  As I said
the option to change it is different from the actual functionality to
do it.  Having half the functionality in core and half in a plugin with
separate code paths would lead to problems.

I think that the benefit/loss is so marginal in each way that we should
keep the status quo, unless there is a really good reason to pull this out?

If you were going to pull that out, you could as easily pull out the window
close/maximize options and continue with most of them.

___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz


Re: [compiz] window matching interface and the new match option

2007-02-27 Thread Mike Dransfield

David Reveman wrote:


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.
  


I will have a look at PID and window size matching using greater
than and less than, the others are not so important now.

Also do you think it would be OK to add an override redirect match?
It would make it possible to work around a few toolkit bugs (ie. the 
mozilla

menu problem)



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.


It sounds good :)

___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz


Re: [compiz] window matching interface and the new match option

2007-02-27 Thread David Reveman
On Tue, 2007-02-27 at 16:39 +, Mike Dransfield wrote:
 David Reveman wrote:
 
  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.

 
 I will have a look at PID and window size matching using greater
 than and less than, the others are not so important now.

Great, another one that I think can be useful is 'depth' or 'visual'. So
you can match based on if a window got an alpha channel or not.

 
 Also do you think it would be OK to add an override redirect match?

Yes, I though about adding that too.

 It would make it possible to work around a few toolkit bugs (ie. the 
 mozilla
 menu problem)

Yes, it's nice to be able to push workarounds like this up to the option
level.
 
 
 
  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.
 
 It sounds good :)

OK, I'll do that then.

- David

___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz


Re: [compiz] window matching interface and the new match option

2007-02-26 Thread Mike Dransfield

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

___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz