- User Since
- Apr 18 2015, 8:19 AM (165 w, 3 d)
Mon, Jun 18
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.
Sun, Jun 17
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.
Sat, Jun 16
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.
Thu, Jun 14
I would appreciate a unit test for the issue.
Mon, Jun 11
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.
Sun, Jun 10
Thu, Jun 7
Wed, Jun 6
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.
Tue, Jun 5
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.
Mon, Jun 4
Sun, Jun 3
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.
Sat, Jun 2
As indicated in the discussion on the task I'm against this change.
Fri, Jun 1
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.
Thu, May 31
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.
Tue, May 29
Sun, May 27
What about moving this directly to Effect or AnimationEffect?
Thu, May 24
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.
Wed, May 23
Please as bugfix to 5.12 branch.
An example for how my proposal could look like:
If we move 3rd-party apps to using CSDs per your proposal, Can the proposed window rules force a shadow and titlebars for them, in addition to forcing no borders?
Qt virtual keyboard is unfortunately unsuited on an X11 session.
Sorry but I don't think you understood my proposal. My proposal requires changes in application - I mentioned kirigami as that is under our control. If we cannot change the code we need to look for a different solution. What I wrote is divide and conquer: find the correct solution for each class if application. The default for all applications would be no change. It's opt in. So no application would lose borders or shadows. As a fallback if applications cannot be patched, we can use window specific rules to enforce no side borders. This would work for everything except Elektron as Elektron is not icccm compliant.
Tue, May 22
GTK apps that use CSDs don't have window shadows, and it looks bad. We get a neverending stream of complaints about this.
I wouldn't change plasmaquick based on KWin's behavior. KWin is weird after all. We should rather work around inside KWin.
wonderful! Thanks to you two :-) And yes as soon as you push this change you can push the kwin change.
Mon, May 21
First on all about how to reach me: please don't expect me to hang around in telegram or irc to wait for anything design related touching my expertise. That's not possible, I just cannot monitor everything, my time is limited. Instead reach out to me or anybody else when you have something which requires my or anybody else feedback. Don't come up with technical solutions leave that to the technical experts, just like we technical experts should not come up with design solutions. I must say I found this process today frustrating and reading your answer I have a feeling that it was also very frustrating for you as well. I don't want to fight with you, we are in the same boat. But technical decisions should be done by those best understanding the technical area, for that you need to bring us into the boat quite early. I'm glad that I found this today by chance as if you would have opened a review for the change in KWin, I would have vetoed it.
If I have not done that thoroughly enough, please feel free to refute my points and I'll respond accordingly.
I just looked through the list of aurorae themes I have installed and there are quite a few which visually break with no side borders. Please also think about the consequences for themes not being the default theme which you can influence. (Although it looks like Aurorae always renders at least 1 pixel for no border).
I'll now provide some technical detail behind the dropdown and the options. This was never meant to be a designable option. If you compare kdecoration 1 and 2 you will notice that the decoration border size moved from being a per-deco to a global option. The main reason for this was that KWin considers the border size to be an accessibility feature which is so important that themes are not allowed to influence it. The decoration theme engine I wrote (Aurorae) provides a high level of customization to the theme designers, but borders sizes are not included. Exactly because it's an important accessibility feature.
The decoration border sizes are an accessibility feature. That's why they are designed as a KWin config property and not as a decoration/theme property. I know it, because I implemented it. Given that I disagree on that this is only a change affecting VDG, but a change which affects my technical expertise. I urge you to consider that I have experience of > 10 years on working with the decorations. Please don't just discard my feedback.
I'm against such a radical change by default. This makes it impossible to resize the window.
Let's rather do this on an application case by case and experiment first with a few windows.
Please note that every window can specify the color scheme for the decoration. I haven't seen this mentioned yet, but it might be an interesting aspect to consider.
May 20 2018
For more information about Drive-by downloads see: https://en.wikipedia.org/wiki/Drive-by_download
You would also have to run a malicious application which is quite unlikely if you stick to vendor packages (but sure, there probably is a very small chance that a malicious package lands in the dist repository).
-2 from me. That is against our focus of providing secure software.