[PATCH weston] Add config option to disable input method

[Pekka Paalanen]

On Tue, 09 Jun 2015 10:16:40 +0200
Jan Arne Petersen <janarne at gmail.com> wrote:

> 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.

Hi,

do we have an implementation of the compose input method?

We'd still want weston-keyboard to be available on supporting shells,
so I think the changes I proposed for Weston still make sense. If
text_backend_init() ever gains support for choosing what input
method(s) to initialize, we would want the shell to tell it what
it supports to avoid the same problem in the future.

This is all just Weston-specifics anyway, right?


Thanks,
pq

> On 09.06.2015 08:57, Pekka Paalanen wrote:
> > On Mon, 8 Jun 2015 19:46:25 +0000
> > Murray Calavera <murray.calavera at gmail.com> 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
> > wayland-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> >
>