- User Since
- Apr 18 2015, 8:19 AM (217 w, 1 d)
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.
Jan 23 2019
Keep in mind that the Nvidia driver triggered endless loops in checkglerror.
Jan 22 2019
Could this be our firefox issue?
Cool stuff! I assume you want to push together with a patch fixing this?
Do the tests pass without the change?
That's an evil twist. Idea: make the windows panels with windows go below?
The human error exists as long as clang-tidy is not used. What I fear is that someone does a hand porting - we have seen several attempts to do that in KWin from various developers. If devs don't know and now fix the warnings, they can bring in human error.
Stays on top is wrong. The window needs to be in the dock layer, not in the above layer. With keep above other keep above windows can still go on top of it.
Jan 21 2019
Stupid question: the popups are transient to the panel? If yes we can fix in layer. A panel transient should be in panel layer and thus above the windows without any client side tricks.
Suggestion: we take this for stable branches and switch to doing it ourselves in master.
I'm not totally happy with calling it popup behavior. In X speak this is not a popup.
For done code this warning is pointless and negative. I invite you to work with a code base like KWin where it is more important to have a working git blame than protection for theoretical problems. Nobody will be able to guarantee that a 500+ change to add override won't break. Human errors happen, nobody will be able to review something like that. Addressing this warning by adding override all over our legacy code base has a serious risk.
Jan 20 2019
This causes in KWin 500+ new warnings. Do you really think it's a good idea to spam all of KDE with new compiler warnings. KDE has an old code base. We cannot enable warnings for the way you developed C++ for 20 years.