Hi,
I think it is more a problem with weston-keyboard and not with input
methods in general. A compose input method does not need any support
from the shell plugin. Instead of falling back to weston-keyboard as a
default we should just use a compose input method by default.
Regards
Jan Arne
On 09.06.2015 08:57, Pekka Paalanen wrote:
On Mon, 8 Jun 2015 19:46:25 +0000
Murray Calavera <[email protected]> wrote:
Rather than this new config option, I would be much happier seeing the
shell plugin directly indicating whether it supports input methods or
not.
I'm not too sure about this, but I think the text backend has to be
initialized first so I don't know how it can be launched or configured
from the shell plugin.
Hi Murray,
is the problem with the seat_created_signal getting triggered too early?
I think I see it:
backend create compositor
weston_compositor_init()
hook up the seat_created_signal for text backend
backend input init
seats created -> callbacks triggered
Ok, so the text backend relies on seat_created_signal being triggered
also for initial seats.
However, also desktop-shell/shell.c hooks into seat_created_signal, and
it does it much later when the compositor has already been created. It
manages the existing seats explicitly:
http://cgit.freedesktop.org/wayland/weston/tree/desktop-shell/shell.c?id=1.8.0#n6734
I think the text backend should do the same instead of relying on the
init ordering, which is obviously fragile.
If you do that, I think you should then be able to move the
text_backend_init() call into shell plugin's module_init(), right
after input_panel_setup() call.
If you add a config option like this, then the user must somehow know,
that when using this particular plugin, he should set this other config
option too. That seems cumbersome, because the plugin itself certainly
knows if it supports an input method or not. Why should the user be
second-guessing the plugin?
The way I stopped the user having to specify the config option was by
shipping a "my-cool-plugin.ini" file which had all the neccessary
options(shell .so file, disabling features that dont work and
extra plugin-specific config options). Then the user can just
type 'weston --config=my-cool-plugin.ini' and everything is taken care of.
The downside being that it also replaces all the other settings too,
since we don't support merging of configs.
If you really need a config option, how about setting [input-method]
"path" explicitly to empty to disable loading the input method client?
I'm not sure if you mean change it so that it doesent try to launch the
input method if path is empty, but currently it will try and fail even
if the path is empty.
Yes, I meant to fix the code to not even try if it is empty.
Rather than this new config option, I would be much happier seeing the
shell plugin directly indicating whether it supports input methods or
not.
I completely agree, but I have no idea how this can be done.
I hope my suggestion solves the issue. Sounds like it would be a 3
patch series:
- text_backend_init() to handle initial seats explicitly
- move text_backend_init() call from compositor.c to the appropriate
shell plugins
- (optional) fix empty "path" to not even try launching the input
method client
Thanks,
pq
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
Jan Arne Petersen | [email protected] | Senior Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
