Radical suggestion: remove kglobalaccel from frameworks and put it into Plasma. Kglobalaccel fails as a framework. It is not cross-platform and not even cross-desktop. X11 backend cannot ensure that the shortcut is not taken by another process, the Wayland backend is KWin specific. We hardly have any applications outside of Plasma using KGlobalAccel. Looking at lxr I can see a few media applications, but we already bind the shortcuts to mpris. There seem to be some API abuses like Chokoq having a global shortcut to update the timeline or konversation to switch to the next active tab.

Just for the record: the patch to add window decoration back is in D13459 - I still have the code around and uncommitted changes on top. With the relatively small changes I had window tabs kind of working already. So if anyone wants to pick it up: we are almost there and I'm happy to share the code. Personally I doubt that I will find the time to finish it. I currently don't even find the time to push accepted changes. I'd love to do it, but I must be realistic.

And of course if this patch lands I have no objections any more to the fake key event injection in the fake input protocol which is required for kdeconnect and remote access.

I'm not convinced that removing the ifdef is the solution to the problem. What you basically want is being able to do an out-of-tree build of a backend. Ideally you would want to install all the variants next to each other and be able to pick the correct one.

This is a wonderful patch - I love it!

In T11067#192498, @hiangel wrote:

Sure, but we here still don't know what those conflicts were, and given this task is about a tiling WM, it sounds possibly important information.

Just something I want to add so that it is documented: In KWin we quite regularly get the request to emulate the right mouse click. This is not possible (and/or advisable). Obviously such a feature would belong into the display manager. Meaning on X11 it must be in the X server (no control from our side) and on Wayland it would be KWin. So let's explain why this wouldn't work on Wayland. On Wayland we have dedicated interfaces for touch and pointer (mouse, touchpad) interfaces. Touch does not influence pointer movement and does not emulate left clicks as it was the case on X11. In case an application would announce that it doesn't support touch, we could emulate mouse on touch events. But this is in practice not the case. We mostly interact with Qt, Gtk and XWayland which all announce touch support. For the compositor it is impossible to know whether the application truly supports touch or not. There is just no protocol to announce "hey I can do touch, or hey I cannot do touch". So KWin would need to handle all applications the same way and if KWin would start to emulate right click events it would break applications which already support touch. For example at $work we use KWin as the compositor for a gui application which was designed for touch screens. We don't have a context menu, but we handle the long press event. The moment KWin would start to emulate right click events our application would break. And this would not be the only one, every application starting to make proper use of touch would break. It is not a future proof approach to add such support to KWin.

Wayland by default would offer a better user experience. E.g. a tear free desktop, less power consumption, different refresh rates per screen, better possibilities to extend our desktop on mobile, better touch support and most important improved security. So yes, the goal as it is framed is focused on tech, but it can easily be reworded to focus on the advantages it gives us in comparison to X11.

In T11067#190977, @hiangel wrote:

• numberFrames -> numberOfFrames
• added missing copyright header

@ngraham I do not understand why you request changes. This diff has no implications on spectacle or any other application. The api call is neither intended to be used by an X11 application nor by a Wayland application and predates the interaction with ksnapshot.

The idea of loading on startup was to verify that the view works and only offer the sni and other interactions if the virtual keyboard is functional - see the early return in line 86. This is IMHO a must have feature as we cannot properly set a dependency on the virtual keyboard qml component. If we can check in another way, I'm all for this change.

Is there a real world situation where KWin is getting compiled twice with different settings? When adding the ifdefs this was based on feedback from distributions

In T11067#190658, @Eiden wrote:

@graesslin
Martin what is you opinion about integration of "smart tiling" (T11086 into KWin? Is it hard to do with current codebase?

I accept your general criticism, but I disagree. When we started Wayland and added the interactive protocol flatpak did not exist (practically) and we still had to assume that everything runs trusted. Even right now it's still a nice theory only that all apps will be sandboxed (on my system they aren't yet). Given that we should also look at the now and present issues. Having these dbus call open was a mistake when adding the interactive mode. Given that I see it as a bug fix to that.

Some more information about the removal of tiling support in: http://commits.kde.org/kde-workspace/34027455aaa2ee738c45987ca2d8cb7d65491bf0 - it has a few links explaining the problems.

In D22033#488838, @davidre wrote:

But there are ways to circumvent this. For example if I were a malicious program I could just call the variant that doesn't take a file descriptor and saves to /tmp and then read the file from there.

The interaction is a security feature. It makes it impossible to just screenshot and leak the information. Please keep this in place. Being able to screenshot was one of the big unfixable security issues on X11. Let's please not remove this. Also having a screenshot api which does not enforce user interaction provides a poor man screencast API. The explicit user interaction makes it impossible that someone tries to screencast through this way.

We had tiling support in KWin and it was a complete failure. The problems was that KWin is a stacking window manager and no matter how hard you hammer on it, it will be a stacking window manager. There are concepts which just don't fit - and that's fine. Maintenance was a hell, especially tiling broke stacking and stacking broke tiling. This is a problem which just cannot be solved.

Having some more time to write. I really do not want to see this option come back. It was the right decision to remove it, I stand to it. I had a shitload of of negative comments due to it and it would have been easy to just revert the change, but from a product development perspective it's wrong to do so. I really need to point out that this is a feature only required by a handful of very noisy and angry users. We don't have to cater to those who scream load but we need to develop a good working product with a streamlined UI and good interaction. While it's true that there are other applications implementing close on middle click, I think it's wrong to offer it on X11. Middle click has a very defined meaning as a fast way to paste. Users could expect that middle click performs a paste action and not close windows.

Please do not add this back. This is a very hot topic to many users, but let me explain. I was the one adding the feature in the first place and I removed it again. Personally I think adding the mouse actions functionality was a big mistake. I did this in 2008 when I joined KWin development. My work on Present Windows back then was a failure. I - and Lucas - added several features which turned the code base into an unmaintainable mess and significantly affected the stability of overall KWin. Several of the features added back then were reverted and replaced by better functionality. What I wanted to achieve back then was having the functionality of closing windows. My big mistake was to make this configurable. Instead of just adding this feature we made it completely configurable and turned it into a space ship control of window management. But nothing else in Present Windows is a window management feature. As the name says, it's intended to present all windows, not to manage them. Furthermore this introduced a big usability issue by reusing Present Windows in desktop grid to present the windows but not having the user interaction feature.

You are aware that kglobalaccel doesn't support removing global shortcuts? If yes your reply doesn't make any sense, if no it means you need to consider now - a revert later on based on feedback is not an available option.

On the other hand you are stealing the shortcut even for users not using this feature at all. What about the following idea: if a user adds the show desktop widget the shortcut gets added?

Sorry, but I don't see the need for this protocol as that is already part of wl_keyboard.

For what is worth to mention: we have for years refused to add further global shortcuts as they very easily conflict with application shortcuts. Yes, we were aware that people complained about the lack of default shortcuts. But on the other hand we get the bug reports about applications being broken. And I keep it with Linus: don't break user space. There's a reason why that shortcut didn't have a default and the windows shortcut existed back then.

Please don't introduce such magic. If you need a special window type please add one or use osd directly. Please keep in mind that there's no way to set keep above for Wayland windows.

When I read the bug report I was wondering whether that's actually intended? Does keep above implies it's kept above other windows in all cases?

Thanks a lot! I suggest to backport it to all supported versions.

Please don't randomly turn methods into slots. There's a fair chance of future breaking if somebody checks for the usage of the slot and notices it's unused.

I think there's no problem with anonymous contributions. We have no means to check anyway if the provided name is correct.

From my side a -1 as we are feature frozen. Gtk can easily check whether the window manager supports this property and if not do the same as this patch does. This is clearly a gtk bug and if gtk fixed it, it works for everyone and there is no need to incorrectly claim support for the property. Has this issue been reported to Gtk devs?

I still don't see a need for this property. All we do is something gtk can easily do itself. We are working around a gtk bug in all window managers. I think that's wrong.

The main problem with subsurface and WindowPixmap is that the subsurface a are evaluated too late in the rendering process which makes it impossible to have quads.

I already expressed my concerns in the bug report: I consider this as featureitis and catering for a specific use case. I fear that the negative aspects of yet another checkbox (c.f. kde is too complicated). Also it creates yet another code path which nobody tests and those special use cases are the ones which tend to break.

Yes the code had a merge conflict. Sorry about that.

See https://phabricator.kde.org/D19084

In D19052#413765, @cfeck wrote:

I would need guidance to write such a test. If I understand it, I would need to create a dummy Client subclass, call setCaption() with different strings, and check what actually lands in the cap_normal variable.

The question is, how can I create a such a dummy Client when it actually requires a workspace? Any tests that do similar things with a different property?

In D19012#412265, @davidedmundson wrote:

or we have the QPainter compositor which also turns QtQuick to use software renderer.

Unfortunately that's not true if we still want to switch at runtime.
QQuickWindow::setSceneGraphBackend is only followed if set before the first QQuickWindow is created.

I think we have a unit test for it which should now expect pass. If I'm wrong and we don't have a test case: could you please add one.

In R108:01ee957c494a43f928342db116075ea430b19cea#3743085, @zzag wrote:

We cannot just call setupCompositing because there is a phase during startup where setupCompositing already passes but the Compositor is not yet fully initialized. Thus it could happen that it's called twice which makes the Scene assert.

When could this happen? Are there prominent functions or methods that one could look into in order to understand why setupCompositing is called twice?

Remove rect.isValid check

Please don't take it negative that I once again request changes here. I once run into this issue myself when I added quick tiling - oh that was a mess, because I didn't track in Client the state changes. Back then Thomas fixed all of it :-) It's just a lesson learned and this geometry handling is really complex. It's too many states and we need to ensure here that we don't jump out of maximized or fullscreen due to keyboard open. Now to make it even more complex one could think about the display getting rotated which would again change the geometries and all the windows changes.

I'm not sure whether it's a good idea to resize windows for virtual keyboard. This can easily result in a feedback loop - the window resizes, the element with focus loses focus, keyboard closes, window resizes, element gets focus again and so on.

One of the long time problem of KWin was that we had too many things in Workspace. Workspace just does too much - it's a god object.

I don't see how this patch could cause Plasma windows to have problems. All changed code is internal windows.

go for it, we have now enough time to notice any regressions till the next release.

Setting the named symlink.

In R108:58fa92e40bd3dd144101ed607b0030ed666b7083#3740146, @IlyaBizyaev wrote:

This commit breaks KWin on Plasma Mobile when HWComposer backend is used: https://invent.kde.org/snippets/5
I'm not sure what XWayland supports, but when I workaround this line by creating a link from /usr/lib/i386-linux-gnu/libhybris/eglplatform_DRM.so to /usr/lib/i386-linux-gnu/libhybris/eglplatform_wayland.so, XWayland applications start and work fine.

Ah I also had it on my to-do list as I noticed it in the internalclient branch.

I really like that this is much more self contained than I expected. I haven't done an in depth review yet.

Now really update (git user error)

Fix style - sorry that's $work coding style sneaking in

If there are no objections I'm going to push this

gcc --version
gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

In D18406#400808, @zzag wrote:

Though I don't see -Wmaybe-uninitialized in my build logs.

Now I have the warnings again:

sure!

I fully agree with Vlad and David: this is not a feature belonging into the compositor and we should not drive by trying to copy features (badly). KWin's mission statement discourages to do so. We had huge problems in the past trying to please too many and failing.