- User Since
- Apr 18 2015, 8:19 AM (182 w, 5 d)
A reason for the old code being weird is that KWin is weird. I remember that I fought quite a lot when porting this to Qt5 and there was a time when it was working.
Mon, Oct 15
Sun, Oct 14
Fri, Oct 12
Thu, Oct 11
Good detection work! The problem you describe is btw. quite common. I remember that any Qt file open dialog caused this behavior. It first created the window than closed it and created it again. That was one of the first very painful Wayland crashers I investigated.
Wed, Oct 10
Please increase the so version of the library as that was an ABI incompatible change.
Tue, Oct 9
Don't focus too much on Plasma::Dialog. It should also work with a plain QQuickWindow or a QuickControls2::Dialog
Sun, Oct 7
Sat, Oct 6
Fri, Oct 5
Just an idea: duplicate all the code and keep the QScript variant to have backwards compatibility. Add the new qml based one and require a desktop file entry to be used there. If we need to break the API anyway, because not everything is 1:1 mapped, let's break it properly and do some cleanup in the API. And then with Qt 6 or removal of QScript we switch over. That would give every user some time to update the scripts.
Wed, Oct 3
It's not about that there are only complaints on Reddit. It's about the user group: do we want to deaign so that the small Reddit community is happy or do we want to design for the rest? Do we want to make the product more complicated (yes that's the result of a config option) to please some people on Reddit while at the same time we already have a mechanism to achieve the same?
Mon, Oct 1
Please don't introduce options based on what's unpopular on Reddit.
Sep 10 2018
I just want to point out that such applications are not ICCCM compliant: This property must be present when the window leaves the Withdrawn state and may be changed only while the window is in the Withdrawn state. Window managers may examine the property only when they start up and when the window leaves the Withdrawn state, but there should be no need for a client to change its state dynamically.
Sep 7 2018
Aug 25 2018
Just wondering: why did you integrate directly into KWin, instead of adding this to the existing helper process? My motivation to use a dedicated process was to ensure that KWin cannot be attacked through the X clipboard (the data is hold by the helper process, not by KWin). If you think having it in KWin is better I suggest a follow up change to move the normal clipboard functionality also into the xwl directory.
Aug 22 2018
Aug 21 2018
Aug 19 2018
I like the other solution better as it doesn't depend on Klipper specific behavior.
I like this solution. As a matter of fact the default options of Klipper are also fine. Only if the not default prevent empty clipboard option is used this breaks.
Aug 18 2018
Someone was giving a presentation during the KDE e.V. meeting and resized a Dolphin window to make it bigger. The act of doing this made the window translucent and revealed the content of the window beneath it. This was a significant privacy violation, and could have had damaging consequences.
Aug 17 2018
Sorry for strange upload, arc decided to no longer like me.
Jul 31 2018
Jul 21 2018
What's really strange is that requestShowTooltip comes from the event loop. But nothing in kdecoration or in KWin goes through a queued event to KWin::Decoration::DecoratedClientImpl::requestShowToolTip.
The hovered state cannot change if there is no decoration. Hover is from an event handler from Decoration. I doubt that this change here can fix the crash. Also that's the explanation for the update slot not checking: no hover change if there's no decoration.
Jul 20 2018
Jul 18 2018
Jul 17 2018
Jul 15 2018
just saying: I really like these changes. Good work, keep it going!
I would turn it around: first think about how to pass the information to the effects. Without that it doesn't make much sense to define which rules exists. Especially have a look how KWin core uses the rules. The common pattern is: something changes, then check in rules the value and use that as the true new value. That pattern is btw. not used in the code of this patch. But for having the rules work correctly and in all circumstances this is extremely important.
Jul 10 2018
go for it :-)
Adding support for rule in effects is not trivial. We have had this idea for years and never found a suitable and implementable solution. Hacking this in for one effect is not a solution. We need a general solution. And that is not trivial as many areas in KWin are lacking:
- effects need to define sensible rules
- rules ui must be able to load the rules for effects
- a way to notify from rules to effects
Jul 5 2018
I think this change is way too invasive. When I drafted that my idea was to not change all in one go but make it backward compatible. Especially not touching anything related to X11 Windows.
Jul 1 2018
Nice. To our defense: c++ wasn't that nice when that code was written.
Jun 30 2018
Jun 28 2018
also on Wayland we have X11 Windows with the negative side effects.
Jun 27 2018
-2 from my side. This has side effects which could in worst case trigger alt+tab to cancel.
Jun 26 2018
+1 from my side. I don't think we would have used it if the QEasingCurve would have existed at that time.
Nate, I cannot believe what I read here. Every week you do a blog post about usability. In other reviews you draw the usability card so often that it annoys me. And here you want to break user setups and break with "form follows function". This is absolutely unbelievable to me.
Jun 25 2018
Jun 24 2018
Jun 23 2018
Except for the virtual I like the change
Please don't play with the users. I would have never pushed a change to test how things work. They are not our testbed. That it worked on other platforms doesn't mean a thing. Maybe that other platform cannot even run into the dead zone situation.
Jun 22 2018
Jun 21 2018
To everyone here: you are extremely experienced developers and software users, partially working in the window manager area. Of course you understand why the dead zone happens and of course you are able to adapt to it. But please think of your users. I fear they won't understand it. Also with click the dead zone might be obvious. With just mouse hover it might not. Please try not to argument for this strong behavior change with anecdotal evidence like "I use this for years".
Jun 20 2018
Jun 18 2018
I realized that there's yet another problem with the approach: if two windows border and the window with pointer focus is lower in the stacking order this would create a dead zone in the window. With compositing disabled this would be worse as there's not even a visual hint.
Jun 17 2018
We don't break users configuration. There is nothing which justifies that. For example: if the user configured a wallpaper the new wallpaper won't replace it. Only default values my be modified by updates. As soon as a user configured a setting it must not be changed. Users need to be able to trust their software.
Jun 16 2018
An advice: don't change the default based on the random feedback you get. If you change this I can promise you you will get the same amount of complaints after the next release.
This would break configurations of users.
Jun 14 2018
I would appreciate a unit test for the issue.
Jun 11 2018
Great work. Could you please extend the unit test for this area. Did you run them? As this is a behavior change I could imagine that it breaks the existing tests.