User Details
- User Since
- Jul 27 2015, 2:36 PM (458 w, 3 d)
- Availability
- Available
Jan 15 2020
Dec 10 2019
Hi, please send me an email with instructions, I'll forward it to Qt Company IT. Reach me at frederik.gladhorn@qt.io.
Nov 18 2019
Nov 12 2019
Sep 25 2019
So how about putting the data into either the bundle location or in Library/Application Support/KDE or some other shared common place?
From the Qt perspective, we want to play by the platforms rules. And the task seems to be very much stuck, so it's maybe worthwhile to re-think if KDE cannot better accommodate the various platforms. QStandardPaths::GenericDataLocation sounds great for shared data.
I don't quite understand the whole data location situation. Are the KDE apps doing something completely non-standard? Maybe it's worthwhile to question KDE's approach at this point, since there seems to be no agreement on that it could possibly viable for mac/win from the Qt people. See comments on https://codereview.qt-project.org/c/qt/qtbase/+/239952
Sep 20 2019
@romangg and @davidedmundson any comments? I think @zzag prefers the class names without the V1. I'd like to progress on this step by step and the generator at least gives a good starting point.
Sep 17 2019
The unstable primary selection v1 protocol produces code that doesn't compile, after this change it does compile - since it expects the version enums for three classes, but only the first one is actually written into the file.
Actually sort all files
Sep 16 2019
Done, now it just needs review and someone needs to push it out on the site.
Note to self: https://cgit.kde.org/websites/ev-kde-org.git/ seems where the document lives.
I really like the change. I have read a bunch of the KWin code and I had no idea what "Smart" was, despite using KWin for over ten years. Simple terms and consistency are clear winners in my opinion.
Sep 15 2019
Sep 14 2019
Looks good to me.
Yes, it really depends on how many casts it ends up being. Maybe with a helper function. I personally think the vector_cast is almost as bad as inheriting the vector.
Nice, makes it easier to read :)
Makes sense.
Thank you arc for messing up my commit message XD
How would it be to only keep one vector of AbstractOutputs in Platform? Then there is no vector copying. A cast should in my opinion not be a memory intense operation in the first place, but just a change of how types are interpreted.
In the sub-classes the outputs could then actually be cast as needed (in a convenience function, in case it's more than one or two places). Hopefully this would also reduce code duplication. Of course it only works if there is only one platform in use at a time (I assume that is the case right now already).
In general I agree with @zzag - composition is better than inheritance since it decouples things.
Many modern programming languages don't even really allow inheritance any more at all.
I wonder if there isn't a solution that avoids all the casting, I cannot say that I'm a fan of the qvector_cast. I didn't really read the code though, just glanced over it.
- Updating D23915: Improve documentation
Fixed two missing spots
Yes, for me always using constBegin/constEnd makes reading the code slightly easier.
Removed stuff from .ui files
Sep 13 2019
Sep 12 2019
Remove more lambda this captures
Sep 11 2019
I seem to have /usr/share/wayland-protocols/unstable/primary-selection/primary-selection-unstable-v1.xml which I'll start with.
Merged in removal of UI
So from what I understand the protocol is defined by the gtk folks, keeping the middle click out of the "core" copy and paste protocol. It needs a bunch of duplication of the copy and paste stuff to implement this. Presumably mostly in kwayland.
Merged into parent change.
Sep 10 2019
Rebased
Rebased
Based on all the +1s, this should clearly go in. Go for it :)
Sep 9 2019
Thanks! I do think that we will work towards better accessibility independent of this. I think we'll have the support of many other developers, but sadly accessibility is not the most mainstream topic. I do intend to meet up with at least @chempfling some time soon (sadly I end up being busy way too often).
I think it was a good exercise to formulate the goal in any case and I think we'll continue to influence other developers to make good choices for all users :)
Sep 7 2019
Remove two more lines
I did the UI changes and kept them separate for now. https://phabricator.kde.org/D23767
I can do the UI changes (and I don't mind re-basing the change if the other one goes in first). Should I squash the UI changes into this patch or create a new change?
On this change: we also have window tabs in the window rule system and also in the configuration system (e.g. middle click to move tabs).
@gladhorn Can you please remove these leftovers?
Aug 16 2019
Yes, so for size hints, this should be fine. For actually placing individual chars and calculating their width in the terminal window I didn't dare changing things.
Aug 14 2019
Aug 13 2019
Use #if defined consistently
This is interesting, since it's around the corner from this crash: https://bugs.kde.org/show_bug.cgi?id=399499 - But of course this patch won't change anything, just make it slightly easier to see what's going on.