This add blur to Rules and RulesWidget
Details
- Reviewers
davidedmundson - Group Reviewers
KWin
I don't know if including KWindowEffects in rules.c is a good idea, maybe adding it to AbstractClient is better?
Video:
Diff Detail
- Repository
- R108 KWin
- Lint
Lint Skipped - Unit
Unit Tests Skipped
The Summary is the text committed to the change history, so please do not ask questions there, but describe your change shortly.
Using KWindowEffects inside of KWin is wrong. Also, it would work only on X11. I think it would be better to add blurBehind(or something like that) property to toplevel and use it later in the blur effect.
Anyway, I suggest to wait for @graesslin.
Adding support for rule in effects is not trivial. We have had this idea for years and never found a suitable and implementable solution. Hacking this in for one effect is not a solution. We need a general solution. And that is not trivial as many areas in KWin are lacking:
- effects need to define sensible rules
- rules ui must be able to load the rules for effects
- a way to notify from rules to effects
Using KWindowEffects inside KWin is an absolute no-go. This is an API intended to be used to inform KWin not to be used by KWin. The behavior is pretty much undefined.
@graesslin, after looking for couple of hours on kwin, kde-workspace and some others repositories i come with idea:
- KWin::Rules will use list of effects(maybe special X-KDE-ServiceTypes) to generate map/vector of all available rules
- every Rule will provide/implement:
- "unique" identifier, for example: blur; that is going to be used to identify it in KCM and KWin::Rules
- KCM(just the row or whole tab bar) for kwinrules.
- special interface which is going to be used by KWin::Rules with virtual methods like: void read(KConfigGroup&), void write(KConfigGroup&), void apply(Rules*), apply(Client*), void discard(Rules*), etc
The only thing that's left is:
- a way to notify from rules to effects
but i will come with idea how to solve that after implementing the things described above.
Please let me know if you have a question or problem with that idea.
PS. I think that is not the best place to discuss about that.
I would turn it around: first think about how to pass the information to the effects. Without that it doesn't make much sense to define which rules exists. Especially have a look how KWin core uses the rules. The common pattern is: something changes, then check in rules the value and use that as the true new value. That pattern is btw. not used in the code of this patch. But for having the rules work correctly and in all circumstances this is extremely important.
So in case of blur it would be that the blur effect needs to check the rules whenever a window gets added or a window changes in a way that the blur behind needs to be re-evaluated. If this setup works or we have a plan how it works then we can look into how to define it. Otherwise we might end up with a system which is not suited for rules. That said: I wouldn't know whether your suggestion would work as I don't know what's really needed to make effects support rules.