[Development] Request to delete libibusplatforminputcontextplugin.so from qtbase

[Knoll Lars]

On 22/07/15 06:49, "Thiago Macieira" <thiago.macieira at intel.com> 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.

The other problem is that people not using Qt as provided by the Linux
distributions would loose ibus support, unless they do quite a bit of
additional work.

We couldn’t easily ship it in Qt neither for both practical and legal
reasons. The practical ones are the items Thiago mentioned. The legal
reasons are that we can’t make it part of Qt without being under the CLA,
due to both the KDE Free Qt Foundation), as well as being able to offer it
under commercial terms to our commercial customers.

Cheers,
Lars