[PATCH weston] Add config option to disable input method

[Jan Arne Petersen]

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

-- 
Jan Arne Petersen | jan.petersen at kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts