[PATCH weston] Add config option to disable input method

[Pekka Paalanen]

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