[Development] Request to delete libibusplatforminputcontextplugin.so from qtbase

[Takao Fujiwara]

On 07/22/15 13:49, Thiago Macieira-san wrote:
> On Wednesday 22 July 2015 12:41:11 Takao Fujiwara wrote:
>> On 07/22/15 00:49, Thiago Macieira-san wrote:
>>> On Tuesday 21 July 2015 16:00:45 Takao Fujiwara wrote:
>>>>> We don't develop gtk. We do develop Qt4 and we know that supporting
>>>>> complex
>>>>> input methods with it was a pain and it often regressed due to lack of
>>>>> testing. I think limiting the testing is doing a disservice to our
>>>>> users.
>>>>
>>>> However I guess you won't complete IBus testings since there are various
>>>> functionalities by languages.
>>>
>>> So you're saying that the Qt testing isn't enough, but IBus itself could
>>> test more? That is, if the Qt IBus plugin lives as part of IBus, it will
>>> get better development and better testing than it does today inside the
>>> Qt sources?
>> Yes, I think it's better to develop and test the IBus plugin together on
>> ibus-qt. qtbase is a big source tree to develop the plugin.
>
> I don't see how the size of a tree is an argument. The Linux kernel is 10x
> bigger than qtbase and people seem fine developing things in-tree there.
>
> The argument you're putting forward is that IBus would take better care of
> testing the plugin and aligning it with IBus features.
>
> What we need convincing is whether the fact that it won't suffer because it
> can't track Qt and the QPA API as closely as it does now. Looking at the 20
> most recent changes to the plugin, almost half are cleanups and updates that
> don't add functionality.
>
> Another important factor to remember is that the Qt Project distributes
> binaries for Linux. Right now, they contain the IBus plugin because it's part
> of qtbase. If it is moved out of tree and its build system is complex, we may
> not ship the plugin anymore and, thus, make it impossible for complex input
> methods to work in user applications that use our binaries (including the Qt
> Creator we ship). So if it's moved out of tree, we will require:
>
>   a) a simple build system, which is not the current one either
>
>   b) that IBus makes sure that the plugin is ready to be released according to
>      Qt's release schedule. If it fails to compile, we won't ship it.
>

OK, thanks for the discussion and explanation.
My main concern is the delay of committing the patches from IBus contributors.
If you would help to speed up the patch integration, it would be great.
I can contribute Qt IBus plugin at the moment and hope patch #115603 will be integrated in 5.6.
If not, let me bring back this topic.

Fujiwara