Keystates, implementing a full Plasma on Wayland
Aleix Pol <[email protected]>
| Newsgroups | gmane.comp.kde.devel.kwin |
|---|---|
| Message-ID | <CACcA1RoqCx4Ue25RhCnbqFTOuRKLzfQ6DDeO15b=Fon9=XhZLQ@mail.gmail.com> |
Hi, I've been meaning to dive a bit into how our wayland implementation works lately, mostly due to some needs that we found in KDE Connect but also because I maintain the keyboard indicator plasmoid. Since the latter problem is much smaller, I decided to give it a go at solving it, review is very welcome. https://phabricator.kde.org/D20191 https://phabricator.kde.org/D20192 https://phabricator.kde.org/D20193 Now here I did what I it seemed to be the "normal" thing to do: Implement the protocol on kwayland then on the client (kguiaddons in this case) and on kwin. KWin implementation worked okay but the whole process of implementing it felt very boilerplate-ey. For kguiaddons I couldn't use the implementation in kwayland because kguiaddons is tier1 (although I didn't realize until after implementing it ^^') so I used QtWayland tooling to implement it there. Now to do that, I came up with a new protocol. Since kguiaddons can't depend on it, I was thinking that maybe it would make sense to have it installed somewhere by kguiaddons and kwayland when it starts generating files, it can fetch it from there. I don't know if you think that's acceptable. Also I don't know if this concept fits in another protocol, that could very well be, if that's something you think it's reasonable to pursue it could be looked into, although it seems to me that it's quite ad-hoc to how we implemented the shell separate to the different components we use. I guess this would ultimately implement this task: https://phabricator.kde.org/T4454 HTH, Aleix