• frameworks coding style (didn't know that existed)
• reworded the container section

Please also extend the unit test to verify the new functionality.

In D17544#376137, @davidedmundson wrote:

course the scaling of the surface needs to be considered.

It doesn't, API states surface-local.

In D17544#376110, @bshah wrote:

I also realized that I am passing this wrong information, I am passing it just keyboard position, which is not what client is interested in if I understand it correctly.

Thanks for looking into it.

I think to say hide the button on mobile is the wrong conclusion. You need to hide it because it overlaps. So hide it based on size. That would also be useful on desktop and not only on mobile.

In D17483#374821, @davidedmundson wrote:

This introduces a new dependency on KWin

It doesn't.
We already link Plasma in Core, that has already dependency on Kirigami.

Guys, code review doesn't make sense if one mobile dev opens a change for another mobile dev and the whole thing gets pushed in five minutes. This gives nobody else a chance to comment. If you want to operate like that you can just omit the review.

It might be required to also adjust the KCM. I haven't tested yet against a running KWin. Also I think this is a candidate for backport to LTS release as we get complaints about non functional touchpad kcm.

In D17426#373168, @zzag wrote:

@graesslin Can I land this revision? Or I should wait until all tests pass again?

Q_UNUSED

Well, I would certainly not want to expose a config option to disable VT switching. I think for e.g. a Plasma session that's a must have, for an embedded system it's a no-go.

In D17304#370672, @apol wrote:

Wouldn't this make more sense as a KConfig setting to override through kiosk?

Are you sure that nothing in windowClosed and finishCompositing accesses EffectsHandler?

During last scripty run we had one random failure again: https://build.kde.org/job/Plasma/job/kwin/job/kf5-qt5%20SUSEQt5.11/221/

Add missing copyright headers.

A more concrete example is the old idea of using KWin in sddm.

In D17280#369946, @zzag wrote:

Wouldn't it be better to have TouchHideCursorSpy in input.cpp?

In D17304#369973, @davidedmundson wrote:

when KWin is just used as a compositor for one application

Do you have a specific use case in mind?

Thanks a lot. This seems to be working - at least running the tests takes significantly more time and the last 4 build succeeded.

In D17097#366223, @zzag wrote:

In D17097#365086, @graesslin wrote:

The problem with the approach is that we cannot secure the kwinrc to which it is written. So the whole thing doesn't really work as long as all processes can write kwinrc. On the other hand it could protect properly sandboxed flatpacks.

Could we use kwallet for such a purpose? Also, do web browsers try to secure the list of enabled extensions?

I don't think that this is useful - sorry. I run out of memory about once every five years, so polling every five seconds is way too often and a waste of resources. On the other hand the time when it happens polling 5 sec is way too low as then we are already dead. This can only happen if an application eats memory and then it's going fast.

As we want to be able to run ctest as developers I think it would be better if the CI would do the check.

Ok, just git blamed it. It was the scripting merge (previous version which has hardly anything to do with todays scripting) and that one had signals at a few stupid points. Also the signals were just added for scripting, so shouldn't be connected somewhere else.

In D17097#364320, @zzag wrote:

In D17097#364318, @graesslin wrote:

(e.g. dedicated permissions for accessing dbus).

So, it would be something similar to what web browsers have when it comes to extensions(e.g. "Access your data for all websites", "Read and modify privacy settings", etc)?

The main reason for not exposing Wayland clients to scripting was that this violates the Wayland security model. Through scripting api the complete windowing system is open again.

Sitting around and waiting sounds totally fine to me.

I'm wondering what the intention was to have it that early?

I would love to see a test case for it.

In D16986#363203, @zzag wrote:

Could you please also add qRegisterMetaType<KWn::Deleted *>() for both testX11Client and testShellClient?

Move the X11 test

In D16979#361761, @zzag wrote:

Shot in the dark: could it be that Kate configures the window size right after it was mapped?

Adjust in the way David suggested.

I'll add the patch to my build and try to reproduce. I got the problem about every third run, so if it runs 10 times without failure I'll call it success