- User Since
- Apr 18 2015, 8:19 AM (174 w, 13 h)
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.
Sorry for strange upload, arc decided to no longer like me.
Tue, Jul 31
Sat, Jul 21
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.
Fri, Jul 20
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.
Jun 10 2018
Jun 7 2018
Jun 6 2018
There's one more case where the no-border resize is problematic: when compositing is disabled. Then we don't have shadows so the resize handles would really indicate it's the other window.
What I'm concerned about is accessibility. Accessibility in the case of users who learned that they need to hover over the border of a window. In case of an adjacent window they get the resize handle of the window, but it resizes the other window. This is totally unexpected and I wouldn't know how to explain this to my mother.
Jun 5 2018
Explaining why I prefer this approach over changing the default in KWin. It mostly comes from a rule for code changes: "it works together with all existing features" (see https://community.kde.org/KWin/Mission_Statement ). KWin ships one window decoration (Plastik as a QML Aurorae theme). As explained Aurorae does not support no (side) border as that doesn't match what Aurorae was designed for and is not possible to add without breaking the existing themes. Thus the change of the default conflicts with an existing feature in KWin and is thus not possible from the rules KWin has.
Personal opinion: I think such comments like namespace or if after a closing braces don't add any useful information. If I need to know the scope the brace ends I use the editors functionality to highlight it.
Looks like there were quite a few surviving the script during qt5 porting.
Jun 4 2018
Jun 3 2018
Figured out why everything is crashing and could test now.
> To Martin, on the window rule: I know this is not the right place to discuss it, but still:
It would be really nice to have ! Right now both oxygen and breeze decorations implement "exceptions" which are essentially a crippled version of window rules. Moving the window border size out of this crippled version to the upstream and more feature complete version provided by window rules would be quite awesome.
I like this approach. What I had as idea was to make border size a property of DecoratedClient and introduce a window specific rule. I haven't followed up on it as the vdg did not show any interest in me improving the code side of things.
Jun 2 2018
As indicated in the discussion on the task I'm against this change.
Jun 1 2018
As you can see from the review comments I'm not too happy with the constant need of static_cast. To me that always looks wrong. If one needs to cast something is wrong in the design. I think this can be changed so that in the subclasses there is no need to static_cast or at least have the static_cast in a save way combined with static_asserts to make sure that it is save. The problem with static_cast is that further refactoring could break it really bad. It might still compile but fail at runtime. Just like a c-cast it kind of has a smell.
We are not going to clip anything away from the windows. Sorry, but we cannot do that. It's in IMHO absolutely evil to clip away window content. If you want round borders follow the approach I outlined.
May 31 2018
My comment was not a veto, it was meant as a different thought perspective.
In general I'm against adding new effects to KWin and would rather prefer to remove effects such as scale in. I think everything which is not default should be on store.kde.org and not added to KWin directly.
May 29 2018
May 27 2018
What about moving this directly to Effect or AnimationEffect?
May 24 2018
what does the test suite say about it? Are all tests still passing? Also do you think it's possible to create a test case for it? I think I tried in the past and didn't succeed.