- User Since
- Apr 21 2016, 2:20 PM (156 w, 2 d)
Sat, Apr 13
Thanks. Don't forget to add the isValid check to the KWin patches now. Maybe also add a comment to the KWayland code, what's the reason for the separate create() call and that we want to change this in KF6 via a virtualized create method.
Fri, Apr 12
Can it multi-inherit?
The xml file is missing form the diff now. Don't forget to add it when pushing.
Tue, Apr 9
Note that keepassx != keepassxc.
Fri, Apr 5
Thanks. Having a two-level structure with system defaults (that can get updated via new versions) and static user-overrides would be nice, but I assume it's not easy to do with KGlobalaccel or a "replacement"?
Thu, Apr 4
Nice work. Most of the stuff in libinputtouchpad.cpp and its header file are copy-paste from the Wayland backend. It would make sense to have a new abstract parent class such that the code is shared.
Mar 20 2019
Fixed with 1f3fd6379079
- Rebase on master
Mar 13 2019
Mar 12 2019
Without going through it in detail the overall structure looks really nice now. I'm really happy with the integration in the new version, in particular that our normal AMS code path is used for mode switching. Wait for another +1 by someone who can test it on a live system. But from my side it's good to go.
Feb 25 2019
Superseded by D19255.
No, it wouldn't. But you know what, fix your faulty patches yourselves. I have enough time wasted on this super-small issue. Get your priorities straight!
What's the use case? Why would someone want to enable only half tiling, but not quarter tiling?
Feb 24 2019
Ok, maybe then change the wording in the paragraph a bit on comit. To me it sounded like there is still a problem going on, but it seems since the variable with improper name has been removed, everything is fine now. Your decision.
Code makes sense, but what exactly do you mean by:
Also CCBUG: 400987
Maybe add a TODO comment on merge to the setLogicalSize (that it does not handle the size plus scale change correctly in every case).
I just tested it and it works. As you said in D19253 has same caveat as I pointed out not being in sync with wl_output::done event in case resolution and scale factor change at the same time such that logical size stays the same.
Feb 23 2019
Although this doesn't directly work, I assume because xdg_output property changes can come in on bind, while the wl_output properties are sent explicity. I'm leaving this diff as it is now again up for review, so we can discuss a proper solution. I fear we need to remodel the XdgOutputInterface class completely.
Instead of checking against xdg_output current values, check if wl_output's values have changed resulting in a done event.
Feb 22 2019
Nicely structured. Great!
@bshah noted that there is prior conceptual work about Plasma on TVs (or in general with only very few inputs) here:
- Review comments
Will be pushed after 5.56 branched off.
QRectF with negative size is untested.
- Rebase on master
- Review comments
Tests fixed with e96da56f8ced.
Oh I do care about readability. Did you notice the huge diagram so auto test readers have a picture of what the test is doing?
I'm not convinced by "current autotest fails without the change on current master and works with the patch". Please make the test simpler. I don't think that it will take too much time to reorganize the test table.
What's not to be convinced here? It's a fact, not an argument. No, I won't rewrite the test. If you want the autotest differently, do it yourself.
Feb 21 2019
27 autotests fail now.
- Long variable names
I'm fine with that. If later on we can use KScreen the config entry will become simply irrelevant.
Feb 20 2019
Feb 19 2019
Other aspect which is important to me long-term: is multi-GPU support of different vendors possible with the current patches or a separate backend? Current patches don't seem to allow that easily to add later on. Depending on DRM access in a separate backend it might be simpler to do later.
Right, but how is the way changed?
Other cases where the window geometry on the phone changes is when the screen is rotated or the virtual keyboard is pushing the window like @mart proposed
FYI there is previous discussion in T9780 in regards to touch window resize/move. The goal must be that whatever is he result here is usable in all IOUPs with primary or additional touch input. Therefore let us continue discussion there.
True. Anyway I'm not sure if changing the scale is something we want or if the KWin internal scale should really only be influenced by the resolution/size in a uniform way over all devices.
Because of the low to middle viewing distance and primary input device being keyboard and mouse the window border size can be "None" till "Normal". Currently it's "Normal" per default I believe but there was some discussion to set it to "None" in the past. Another topic is the buttons sizes, which is independent of this value.
I've created some sub-tasks to discuss definition of some common usage patterns we might want to concentrate first: Desktop, Phone, TV.
That's true. So the Wayland event message must be sent also on these hot-plug events or when the user does a manual override, what maybe warrants a separate protocol.
The problem is not so easy to solve I believe now and needs a more holistic approach. Let's go back to the drawing board.