- User Since
- Apr 18 2015, 8:19 AM (235 w, 9 h)
Aug 12 2019
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.
Aug 5 2019
Jul 20 2019
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!
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.
- numberFrames -> numberOfFrames
- added missing copyright header
Jul 16 2019
Jul 13 2019
@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
Jul 2 2019
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.
Jul 1 2019
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.
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.
May 10 2019
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.
May 8 2019
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.
Apr 5 2019
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.
Apr 2 2019
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.
Apr 1 2019
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?
Mar 26 2019
Mar 25 2019
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.
Mar 12 2019
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.
Feb 27 2019
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.
Feb 25 2019
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.
Feb 22 2019
Yes the code had a merge conflict. Sorry about that.
Feb 21 2019
Feb 17 2019
Feb 16 2019
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.
Feb 14 2019
Feb 11 2019
Remove rect.isValid check
Feb 10 2019
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.
Feb 8 2019
Setting the named symlink.
Feb 6 2019
Feb 5 2019
Jan 29 2019
Ah I also had it on my to-do list as I noticed it in the internalclient branch.
Jan 28 2019
I really like that this is much more self contained than I expected. I haven't done an in depth review yet.
Jan 27 2019
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 (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.
Now I have the warnings again:
Jan 26 2019
Jan 25 2019
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.
Jan 24 2019
Hmm... I would say we need to figure out the intention behind force temporarily and whether this concept can be mapped to Wayland.
Could you please add a test case
Could you please add this to the test case. IIRC we have already a few tests for force temporary.