Am 2017-04-08 01:04, schrieb Weng Xuetian:
On Friday, 7 April 2017 06:46:03 PDT，Martin Gräßlin wrote：
Am 2017-04-07 07:56, schrieb Takao Fujiwara:
>> Due to that: no chance for IM controlling part of our stack. We
>> control the IM.
>
> Probably I think this way would not work with IBus.
> Each IBus IME are called by IBus dbus method. You hardly ask each IME
> maintainer to change the protocol.
> IBus daemon would be the controller of IBUs IMEs.
I think I need to describe in a better way how I envision the future
architecture.
I want to have the IM daemon merged into the wayland compositor. So
KWin
would talk directly with the IM through library calls and the composed
text would be sent from KWin to the application through the Wayland
text-input protocol.
I want to eliminate the IPC between applications and IM daemon.
If we are going to touch this code we can strive for the best solution
and not keep stuck on the approach used on X11. And yes that might
need
adjusting the IMEs. But they need to be adjusted anyway. We wouldn't
have this discussion if it would just work on Wayland.
Cheers
Martin
I'm sorry to point out this won't really works. The Xwayland client
will have
to use XIM anyway.
Let's please completely ignore the legacy world in the planning for the
future. We setup the perfect world and then look how we can make
Xwayland work. Even ignoring X11 might be an option as Wayland will now
get a massive push thanks to Mir finally being dead.
From security point of view, I'm ok if the daemon doesn't directly
connect to
application. But I don't want kwin to run the daemon within kwin's
process. It
would impose too much complication and I will not be comfortable about
that.
I don't mind the IM daemon being part of KWin.
People will need to load certain concrete input method as a plugin, I
don't
think kwin itself want to include yet another plugin complex system to
be
running inside kwin.
I don't mind that either.
Just think it something similar, will kwin merge plasma? I don't think
you
really want to that.
Well we merged:
* kglobalaccel
* screenlocker
* keyboard kded
* virtual keyboard
* multi screen functionality
* Everything that X-Server does
* ...
No I wouldn't mind merging plasma if it would make sense and improve the
overall experience. That's what I care for: offering the best possible
and secure experience. If that requires merging yet another daemon I
don't mind. There are no sacred cows to me. We are changing the complete
architecture of the display management, so I don't have a problem with
rethinking everything.
So the best solution IMHO, is to let kwin to expose certain feature
that will
only be allowed to be accessed the im daemon that kwin starts, which
means
user any not arbitrary launch a daemon and do whatever they want. And
that IS
what current wayland's im protocol is doing.
Also, talking about the layout, I don't think you really want to write
the
layout control code. I have never seen a developer who only use
keyboard
layout stuff knows what kind of feature that input method could
achieve.
Please note that only the Wayland compositor is able to set the keyboard
layout. That is a technical restriction of the Wayland protocol. So yes
KWin must (!) manage the keyboard layout no matter what IM devs think
about it. It just must be in KWin.
Compositor should really give this kind of freedom to input method
daemon. It
doesn't expose extra security issue if you think about it. kwin would
just
works like a router that talks with input method via wayland protocol.
And
kwin will not talk with some random input method daemon that it
unprivileged.
I don't mind giving IM some freedom, but at the center of the
interaction there is KWin.
So for me the requirements are:
* no key events are sent via DBus
* applications do not talk to IM daemon
* QT_IM_MODULE must not be used as that breaks virtual keyboard
handling
* No IPC in the key event handling code of KWin
I don't mind whether the IM daemon is a separate process only KWin
interacts with or a library KWin links. I think a library would be
better as that removes the need for IPC and allows to directly involve
the IM from keyboard handling code. Please compare in that point to
kglobalaccel.
On X11 kglobalaccel only listens to the key events which would trigger
the shortcut and it's restricted by things like keyboard grab. On
Wayland KWin can send any key event through kglobalaccel as it's linked
directly. This allows us to make way better decisions as we have a
global view. We can decide whether right now a global shortcut makes
sense or not and then not send it in.
Please note that I look at this from an absolute engineer perspective. I
don't care how it was in the past and only look at how it should be in
the future. Especially given that the situation on X11 is bad. I don't
want users to have to configure anything. If we add this to KWin it will
not be a fringe feature which users have to manually enable. It will be
a core part of the offerings. It will mean that every distro will have
to ship with IM enabled and configured by default. Just like we just
pushed all distros to enable virtual keyboard by default. I'm not in
this to slightly improve the situation, I'm aiming for the best solution
and nothing which is not perfect for the user from both a security and a
usability perspective in future is acceptable to me. The approach must
just work, without having to specify plugins to load in Qt or in Gtk, it
just must work OOTM. Just like we did with the virtual keyboard.
Cheers
Martin
