Hi, please send me an email with instructions, I'll forward it to Qt Company IT. Reach me at frederik.gladhorn@qt.io.

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

@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.

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

Done, now it just needs review and someone needs to push it out on the site.

https://cgit.kde.org/others/fiduciary-licensing-agreement.git/

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.

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.

1. 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

fixup

Remove more lambda this captures

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.

Rebased

Rebased

Based on all the +1s, this should clearly go in. Go for it :)

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 :)

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?

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.

See also https://kdepepo.wordpress.com/2019/08/05/about-deprecation-of-qfontmetricswidth/

Use #if defined consistently

In D23120#511135, @zzag wrote:

There seem to be frequent crashes in the quad version of this code, but
this change should not make any difference from what I can tell.

I doubt that kwin crashes because of alignment issues. I suggest looking into whether GLVertexBuffer::streamingBuffer() is still valid.

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.