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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.