Clipboard managers and middle click paste are new protocols.
We want to be able to copy from a clipboard manager to a regular
clipboard and vice versa without duplicating loads of code.
If we support kliper's "syncronise contents of the clipboard and
selection" inside the compositor that would become an unmanageable amount
of combinations.
It also potentially allows the idea of our XWayland bridge not being a
wayland client and simplifying that code.
Unit test passes
| Lint OK |
| No Unit Test Coverage |
| Buildable 26327 | |
| Build 26345: arc lint + arc unit |
I haven't looked at other patches in the series yet, but I'm not sure that abstracting data sources is good in long term.
The problem with many wayland wrappers is that it's really tempting to abstract them because of DRY. While it's all good in short term, it's not guaranteed to be the same way in long term. wlr_data_control_unstable_v1 is an unstable protocol, so it would be more preferable not to re-architecture our data source abstractions since they may not be suitable for v2 or v3, etc.
Also, given that kwayland-server is on KDE's GitLab instance, I propose to do code reviews there from now on.
Abstracting 1-1 entire protocols hasn't been a good idea, completely agree.
But abstracting small contained concepts within that is not the same thing.
A clipboard will always have a list of mimetypes and a way to fetch data for a given mime no matter the protocol.
| src/server/abstract_data_source.h | ||
|---|---|---|
| 31–33 | For consistency sake, it would nice if method definitions were in the cpp file. It's quite common pattern in kwin to see method definitions both in header files and cpp files, which causes so much pita when one needs to lookup a method definition of the same class. Also, no semicolon after Q_UNUSED (I think Qt Creator will highlight it as a warning) and methods. | |