On 22/07/15 12:17, "Takao Fujiwara" <[email protected]> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
