A better state

[mikedee]

There is now a framework in core for matching windows and a plugin which wraps it to provide regex matching for various window parameters.

The state plugin as it is serves 2 functions, matching windows and setting window attributes (based on these matches).

What I am thinking is to split the current state plugin and move the matching functionality into the regex plugin.

Once this is done we should be able to write another state plugin which uses the window matching from core rather than the built in stuff. I propose that we use KDE's window matching functionality as a base and aim for state to have that functionality.

The benefit of this way is that we can have multiple match expressions (eg. window is firefox and title matches *compiz*). Having this is core and the regex plugin means that other plugins will be able to use the same pattern matching without having to reinvent the wheel. This will make it possible to put window animations onto very specific windows. The window matching we have now is rather basic.

The main problem that I can see is serializing the logic and values to compiz option value types. We do not have to worry about how the user will enter this raw data since the settings manager should deal with that.

I think I could do it by myself, but I am looking to see if anyone else would like to help (particularly with the state plugin side).

[iznogood]

I propose that we use KDE's window matching functionality as a base and aim for state to have that functionality.


can you explain that a bit more please??

Also i think that we would not need to rewrite state. Maybe a bit refactoring should do it, but i am not sure exactly what you have in your mind.

[mikedee]

can you explain that a bit more please??

If you go to kcontrol and select window specific features then you can see the kwin version of state. We should aim to be feature complete with this. I didn't mean anything about sharing of code or anything like that.

There are a few things which kwin controls but that state does not.

Also i think that we would not need to rewrite state. Maybe a bit refactoring should do it, but i am not sure exactly what you have in your mind.

I thought that initially, but after a few quick hacks it wasn't looking pretty so I thought it would be easier to write a state plugin which only sets states, the current version has the matching quite deeply embedded. Writing a new state plugin might also allow for more complex matching and values than we have now.

[iznogood]

I thought that initially, but after a few quick hacks it wasn't looking pretty so I thought it would be easier to write a state plugin which only sets states, the current version has the matching quite deeply embedded


I agree, i don't like it either and some of it was written by me. If we only need to set values it gets a lot less complex. Another thing that directly affected it was that set above-below did not work on createNotify(at least for me). If there is a better event to hook the setting of window props then all these are not needed.
Also setting the props at the wrong event (mapNotify) made some animations to fail (maybe because of some extra windowDamage calls, not sure) so the code needed to run only once.

If there is an answer to that then i guess that most of the code of the original state plugin plus gnumdk's options should work just fine.

Anyway these are just my thoughts and any comments are welcome