- User Since
- Apr 18 2015, 8:19 AM (200 w, 23 h)
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.
Thu, Feb 14
Mon, Feb 11
Remove rect.isValid check
Sun, Feb 10
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.
Fri, Feb 8
Setting the named symlink.
Wed, Feb 6
Tue, Feb 5
Tue, Jan 29
Ah I also had it on my to-do list as I noticed it in the internalclient branch.
Mon, Jan 28
I really like that this is much more self contained than I expected. I haven't done an in depth review yet.
Sun, Jan 27
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:
Sat, Jan 26
Fri, Jan 25
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.
Thu, Jan 24
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.
Wed, Jan 23
Keep in mind that the Nvidia driver triggered endless loops in checkglerror.
Tue, Jan 22
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 can cover?
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.
Mon, Jan 21
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.
Sun, Jan 20
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.
I guess the idea of the old code was to get a possibility to see which one fails to unload.
Given that it compiles, it looks fine to me
Maybe we shouldn't rely on Qt doing that for us, but just do it ourselves.
Jan 17 2019
This does not take into account: A server should avoid signaling the frame callbacks if the surface is not visible in any way, e.g. the surface is off-screen, or completely obscured by other opaque surfaces.
Jan 16 2019
Can't we simplify by connecting once to rowsChanged signal?
make findWindow(QWindow*) also work for X11 by looking through Unmanaged
Jan 14 2019
- Add EffectsHandler::findWindow(QWindow*) -> EffectWindow*
- Fix coding style
Jan 13 2019
I wouldn't start porting away from foreach before Qt 6 has it removed. Quite simply I don't think it will be removed. foreach and extended for behave differently as the qAsConst things show. Using extended for on Qt container is extremely expensive (let's ignore the fact that we know that stuff, think of the average developer with hardly any Qt background).
Jan 12 2019
Oh, I wasn't aware of that. Where do you have that information from? I'd love to read up about it.