[Development] Request to delete libibusplatforminputcontextplugin.so from qtbase

[Thiago Macieira]

On Tuesday 21 July 2015 14:36:19 Takao Fujiwara wrote:
> > * We need at least one input context to use and test against (on Linux)
> > when developing Qt further. Not having the plugin in qtbase will lead to
> > us not testing IMEs on Linux anymore, something I really want to avoid.
>
> I think you don't have to require IBus but other IMFs likes qt4.
> gtk also does not include the IBus modules in itself.

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.

> > * The license is more flexible (LGPL/commercial dual licensed) on
> > qt-project.org, and thus more suitable for some of our commercial
> > customers as well
> If you use IBus, you need to accept LGPL.

That is true for IBus itself, but not to the plugin that exists in Qt's source 
code. Therefore, applications that link to Qt under commercial terms are not 
affected by IBus's LGPL requirements.

Determining whether loading an LGPL plugin into a process non-LGPL process is 
a violation of that licence is entirely unnecessary. We don't need to know 
that.

> > * As Sune said, the platform plugin headers are not stable, so having it
> > in tree will give you a better chance of keeping things in sync with Qt
> > releases
> Some changes are not already acceptable even though the headers are not
> stable. I think we could track the changes with bug trackers.

That's a worse situation than keeping developing at the same pace.

> > * The IMEs for pretty much all non Linux platforms reside in qtbase. Why
> > should we handle Linux differently (except for the fact that there's
> > still a multitude of IMEs on Linux :/ )
>
> But the current IBus module is not useful for users.

Can you explain this a bit more? What are the issues?

> If the patches would not be upstreamed, it could continue to break IBus in
> having the module in qt side.

Why would the patches not be upstreamed?

> > Ideally, I would prefer if things went the other way round and we would
> > also get plugins for other popular IMEs on Linux moved into qtbase.
> I wish to select one of them.
> 1. Move the IBus module to ibus-qt.
> 2. Upstream the patches immediately.
> https://codereview.qt-project.org/115603

Sounds like #2 for us.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center