Interesting! In your "after" video, I notice that the dialog still somewhat awkwardly moves behind its parent window for a moment after you click on the Discard button. Is there any way to improve upon that too?

In D13810#285204, @ngraham wrote:

Interesting! In your "after" video, I notice that the dialog still somewhat awkwardly moves behind its parent window for a moment after you click on the Discard button. Is there any way to improve upon that too?

I'm aware of this problem.

When a modal/dialog is closed, focus goes to the parent window. So, technically, that's correct. The Dialog Parent effect has nothing to do with this.

that can't be implemented in JavaScript.

What specifically?

I think it is a bad idea to go back to c++. From maintainability and hackability the switch to JavaScript was the most important change I ever did in KWin.

In D13810#285327, @davidedmundson wrote:

What specifically?

If a parent window has been closed, "freeze" its current state and force it till Fade/Glide/Fall apart is finished. I think it would be wrong to continue animation in this case because the parent window can't receive focus anymore. Also, as far as I know, that's not possible to "passively" animate windows in js.

In D13810#285443, @graesslin wrote:

I think it is a bad idea to go back to c++.

Well, maybe. One can implement very limited subset of effects with scripted api. For example, Glide effect is just a rotation and a translation, but one can't implement it in js. Even if he/she could, projection matrices should be somehow adjusted at each animation step, otherwise animations will be distorted too much on multiple monitor setups. I think that's not possible to correctly implement dialog parent effect in js.

I don't insist on rewriting this effect in C++, if you think it should stay in JavaScript, I'm okay to abandon this change. But I urge you [KWin folks] to fix this bug. If I recall correctly a bug report, this problem is well-known since 2014 and no one seems to be trying to fix it.

From maintainability and hackability the switch to JavaScript was the most important change I ever did in KWin.

to me, if effects are complicated, there is nothing wrong with going c++ with them
of course one should try to use c++ as little as possible, but when it's way more complicated than a window fading, may be better to have it in c++

Ping.

Yet, they are also limited in what they can do.

Scripts don't have to be limited. It's not a problem of language, it's just a problem of our own exposing wrappers.
You're right that it's an area that clearly needs work. I have porting from QScriptEngine to QJSEngine on my TODO anyway, which will greatly simplify the whole thing.

Anyway, my vision of KWin effects is "slightly" different from the rest so I back off, my goal is to improve KDE Plasma, not to start the C++ vs JavaScript holy war.

Ack. You're doing a fantastic job, and I fully understand that you're doing it with the best intentions and for the right reasons. It's not something I want to have an argument over either.

I'll give the fullScreenEffect problem from the fade patch and this issue a go before the next release, then we'll see where we end up.

In D13810#295880, @davidedmundson wrote:

Scripts don't have to be limited. It's not a problem of language, it's just a problem of our own exposing wrappers.

Well, in some part that's language-related too. For example, if someone wants to implement the Fall Apart effect in JavaScript, he/she needs to update window quads in each frame. IIRC, the Fall Apart subdivides the window grid by 40x40. So, the scripted effect has to loop over at least 1600 window quads in each frame. Sure, at some point the code will be jit-ed. The only way to achieve max performance is to use WebAssembly, but I'm not sure whether Qt supports it and if it does, one logical question pops up "Why didn't you write this effect in C++ anyway?".

IMHO, if one can't implement all effects(starting from the background contrast and ending at the zoom) in JavaScript, there is huge problem with scripted API.

I totally understand that it's not really fun to maintain big number of C++ effects that somehow work(also, the rest of KWin, and other libs) and listen to rude comments on the Bugzilla(like, '<slow clap>'), but, if we push for scripted effects, then scripted effects API have to be complete, it should not hurt performance* and there have to be good reason for having that.

Users should not suffer because of JavaScript preference.

* I know that currently scripted effects don't have problems with performance because they only setup anim data.

FWIW, as I said earlier, I'm okay to maintain effects that I rewrote.