Re: Keystates, implementing a full Plasma on Wayland

Hi Aleix,

I would have approached the problem differently. First of all I don't 
think we need any new protocol for transmitting key state. That's 
already built into the wl_keyboard protocol. The "problem" with this 
protocol is that it only sends events to the focused application, which 
makes it not a direct solution for applications like Plasma which need 
to show the state all the time. For all other applications it would be 
fine. Firefox doesn't need to know the state if it's not focused.

Now I see two possible ways to solve this problem:
1. Just send the modifier changes to all applications
2. Add a protocol to be a special application to get the modifier 
changes all the time.

The first solution is a minimal change in KWayland, but has the 
disadvantage that all applications get the state changes which means we 
are leaking information and cause useless wakeups. It's a fast solution, 
but would work. The second solution is probably the better one.

Concerning the problem of kguiaddons being tier 1 I also had already 
drafted some ideas (see also https://phabricator.kde.org/T4454 ): what 
we need to do is the same as we did for kwindowsystem and kglobalaccel. 
Add a small private library and implement it in kwayland-integration. 
That way the framework can stay tier 1 and doesn't need to depend on 
kwayland nor on QtWayland. If you run a Plasma/Wayland session it gets 
pulled in and works.

Cheers
Martin

Am 2019-04-02 02:13, schrieb Aleix Pol:
> 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