[Development] Request to delete libibusplatforminputcontextplugin.so from qtbase

[Knoll Lars]

On 22/07/15 12:17, "Takao Fujiwara" <tfujiwar at redhat.com> wrote:

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

Feel free to add me to reviews you have, and I’ll try to help with it.

Cheers,
Lars