Re: [compiz] window matching interface and the new match option
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
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
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
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
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
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
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
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
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
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
