Re: [Development] Updating the minimal supported version of libxcb

[Paeglis Gatis]

> Another question is what to do with the bundled libraries?

The -qt-xcb switch is there to reduce run-time dependencies. There always will 
be somebody who wants
to run the latest Qt version on some old linux distribution. 

Also I think it was decided that in Qt5 we can remove support for 
-no-x11extenssion-name switches in the Qt
configure script. There is always -qt-xcb available if your distro does not 
provide the required dependencies. And it does not add any value not to 
compile-in the extension code. It should be a runtime decision, if X server has 
an extension available, we use it.


From: development-bounces+gatis.paeglis=theqtcompany@qt-project.org 
 on behalf 
of Александр Волков 
Sent: Friday, October 16, 2015 2:02 PM
To: Knoll Lars; Thiago Macieira; development@qt-project.org
Subject: Re: [Development] Updating the minimal supported version of libxcb

16.10.2015 09:28, Knoll Lars пишет:
> On 15/10/15 17:59, "Thiago Macieira"  wrote:
>
>> On Thursday 15 October 2015 18:26:23 Александр Волков wrote:
>>> Hi,
>>>
>>> Currently Qt supports libxcb 1.5, which is very old (it was released on
>>> December 3, 2009)
>>> It complicates adding new bundled xcb libraries, because they have to be
>>> checked
>>> for compatibility with this old version and maybe patched.
>>>
>>> Qt officially supports the following platforms that use libxcb:
>>> OpenSuSE 13.1 (libxcb 1.9.1, xcb-proto 1.8)
>>> Red Hat Enterprise Linux 6.6 (libxcb 1.9, xcb-proto 1.8)
>>> Ubuntu 14.04 - 64bit (libxcb 1.10, xcb-proto 1.10)
>>>
>>> What do you think about updating the minimal supported version of libxcb
>>> to 1.9?
>> Unless it's critical, let's do it only in 5.7.
> Yes, I don’t know of larger issues that would require a change in 5.6. But
> for 5.7 by all means go ahead and update the minimum requirement to 1.9.

Another question is what to do with the bundled libraries?
With libxcb 1.9 they are all provided by the supported distros.
The only exception is xcb-xkb, which we require to be from libxcb 1.10.
So my proposal is to remove them from Qt, remove configure options -qt-xcb
and -system-xcb, and use the bundled xcb-xkb library if we can't find
the appropriate version on the system.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Code Coverage Statistics for QtBase

[Paeglis Gatis]

 Why can they be ignored?

I mean, we use only some of the API from that library, but bundle all of it. If 
it is not fully covered by tests it is not an issue.



From: Hausmann Simon
Sent: Thursday, February 19, 2015 4:51 PM
To: Paeglis Gatis; Sébastien Fricker; development
Subject: Re: [Development] Code Coverage Statistics for QtBase

Why can they be ignored? When the users run Qt applications that code is 
executed, so coverage is important IMO.

However if the added code is from build tools (Code generators) then maybe it's 
not so critical, as long as the generated code is covered.

That said, the results look incomplete to me. Qxc‎bwindow.cpp surely has 
non-zero coverage when running tests on X11.

Simon

From: Paeglis Gatis
Sent: Thursday, February 19, 2015 23:45
To: Sébastien Fricker; development
Subject: Re: [Development] Code Coverage Statistics for QtBase



Many of those files are from 3rdparty code, the ones I recognize are from 
/qtbase/src/3rdparty/xkbcommon, those I think can

be ignored when thinking from code coverage point of view.



From: development-bounces+gatis.paeglis=theqtcompany@qt-project.org 
development-bounces+gatis.paeglis=theqtcompany@qt-project.org on behalf 
of Sébastien Fricker fric...@froglogic.com
Sent: Thursday, February 19, 2015 3:51 PM
To: development
Subject: [Development] Code Coverage Statistics for QtBase

Hi,
According http://download.froglogic.com/public/qt5-squishcoco-report/ there is 
a big decrease of the code coverage between Qt5/dev and Qt5.4.
The code coverage from QtBase is decreasing from 56% to 42%.

The first reason of that, is that approximately 100 new files get added into 
the project and the code coverage of this set is near to zero (see the HTML 
attachment and the table below).
This new uncovered files are responsible of a lost of the code coverage of 3% 
approximately.
Question: are these files not tested through an unit test? If they are tested, 
I need to look why they are not taken in account by the code coverage analysis.


The main difference are caused by the code coverage of the unit tests itself.
The number of unit tests did not decrease, but the code coverage of the tests 
with the status Unknown decrease from 13% (from 43% to 30%) and this explain 
the rest of the code coverage lost.
These tests are in fact the code coverage of the code which is running before 
and after a unit test (setup the GUI, common initializations executed before 
main(), exit code, ...).
Question: are they changes between Qt5.4 and Qt5/dev in QTestLib (in the unit 
tests or in QtBase) which could explain this?

Regards,
Sébastien

List of new files:
Source  Coverage (1 means 100%)

action.c0
ast-build.c 0
atom.c  0
compat.c0
context-priv.c  0
context.c   0
expr.c  0
include.c   0
keycodes.c  0
keymap-dump.c   0
keymap-priv.c   0
keymap.c0
keysym-utf.c0
keysym.c0
keywords.c  0
parser.c0
parser.y0
qbasicfontdatabase.cpp  0
qdbusmenuadaptor.cpp0
qdbusmenuconnection.cpp 0
qdbusmenutypes.cpp  0
qdbusplatformmenu.cpp   0
qdbustrayicon.cpp   0
qdbustraytypes.cpp  0
qdevicediscovery_udev.cpp   0
qeglconvenience.cpp 0
qeglfscontext.cpp   0
qeglfsdeviceintegration.cpp 0
qeglfshooks.cpp 0
qeglfsintegration.cpp   0
qeglfsoffscreenwindow.cpp   0
qeglfsscreen.cpp0
qeglfswindow.cpp0
qeglpbuffer.cpp 0
qeglplatformcontext.cpp 0
qeglplatformcursor.cpp  0
qeglplatformintegration.cpp 0
qeglplatformscreen.cpp  0
qeglplatformwindow.cpp  0
qevdevkeyboardhandler.cpp   0
qevdevkeyboardmanager.cpp   0
qevdevmousehandler.cpp  0
qevdevmousemanager.cpp  0
qevdevtablet.cpp0
qevdevtouch.cpp 0
qeventdispatcher_glib.cpp   0
qfbbackingstore.cpp 0
qfbcursor.cpp   0
qfbscreen.cpp   0
qfbvthandler.cpp0
qfbwindow.cpp   0
qfontconfigdatabase.cpp 0
qfontengine_ft.cpp  0
qfontenginemultifontconfig.cpp  0
qgenericunixeventdispatcher.cpp 0
qgenericunixservices.cpp0
qgenericunixthemes.cpp  0
qglxconvenience.cpp 0
qinputdevicemanager.cpp 0
qopenglcompositor.cpp   0
qopenglcompositorbackingstore.cpp   0
qopenglfunctions_4_4_compatibility.cpp  0
qopenglfunctions_4_4_core.cpp   0
qopenglfunctions_4_5_compatibility.cpp  0
qopenglfunctions_4_5_core.cpp   0
qplatformgraphicsbuffer.cpp 0
qplatformgraphicsbufferhelper.cpp   0
qsslellipticcurve.cpp   0
qsslpresharedkeyauthenticator.cpp   0
qstatusnotifieritemadaptor.cpp  0
qunixeventdispatcher.cpp0
qxcbbackingstore.cpp0
qxcbclipboard.cpp   0
qxcbconnection.cpp  0
qxcbconnection_xi2.cpp  0
qxcbcursor.cpp  0
qxcbdrag.cpp0
qxcbglintegration.cpp   0
qxcbglintegrationfactory.cpp0
qxcbimage.cpp   0
qxcbintegration.cpp 0
qxcbkeyboard.cpp0
qxcbmime.cpp0
qxcbnativeinterface.cpp 0
qxcbnativeinterfacehandler.cpp  0
qxcbscreen.cpp  0
qxcbsessionmanager.cpp  0

Re: [Development] Code Coverage Statistics for QtBase

[Paeglis Gatis]

Many of those files are from 3rdparty code, the ones I recognize are from 
/qtbase/src/3rdparty/xkbcommon, those I think can

be ignored when thinking from code coverage point of view.



From: development-bounces+gatis.paeglis=theqtcompany@qt-project.org 
development-bounces+gatis.paeglis=theqtcompany@qt-project.org on behalf 
of Sébastien Fricker fric...@froglogic.com
Sent: Thursday, February 19, 2015 3:51 PM
To: development
Subject: [Development] Code Coverage Statistics for QtBase

Hi,
According http://download.froglogic.com/public/qt5-squishcoco-report/ there is 
a big decrease of the code coverage between Qt5/dev and Qt5.4.
The code coverage from QtBase is decreasing from 56% to 42%.

The first reason of that, is that approximately 100 new files get added into 
the project and the code coverage of this set is near to zero (see the HTML 
attachment and the table below).
This new uncovered files are responsible of a lost of the code coverage of 3% 
approximately.
Question: are these files not tested through an unit test? If they are tested, 
I need to look why they are not taken in account by the code coverage analysis.


The main difference are caused by the code coverage of the unit tests itself.
The number of unit tests did not decrease, but the code coverage of the tests 
with the status Unknown decrease from 13% (from 43% to 30%) and this explain 
the rest of the code coverage lost.
These tests are in fact the code coverage of the code which is running before 
and after a unit test (setup the GUI, common initializations executed before 
main(), exit code, ...).
Question: are they changes between Qt5.4 and Qt5/dev in QTestLib (in the unit 
tests or in QtBase) which could explain this?

Regards,
Sébastien

List of new files:
Source  Coverage (1 means 100%)

action.c0
ast-build.c 0
atom.c  0
compat.c0
context-priv.c  0
context.c   0
expr.c  0
include.c   0
keycodes.c  0
keymap-dump.c   0
keymap-priv.c   0
keymap.c0
keysym-utf.c0
keysym.c0
keywords.c  0
parser.c0
parser.y0
qbasicfontdatabase.cpp  0
qdbusmenuadaptor.cpp0
qdbusmenuconnection.cpp 0
qdbusmenutypes.cpp  0
qdbusplatformmenu.cpp   0
qdbustrayicon.cpp   0
qdbustraytypes.cpp  0
qdevicediscovery_udev.cpp   0
qeglconvenience.cpp 0
qeglfscontext.cpp   0
qeglfsdeviceintegration.cpp 0
qeglfshooks.cpp 0
qeglfsintegration.cpp   0
qeglfsoffscreenwindow.cpp   0
qeglfsscreen.cpp0
qeglfswindow.cpp0
qeglpbuffer.cpp 0
qeglplatformcontext.cpp 0
qeglplatformcursor.cpp  0
qeglplatformintegration.cpp 0
qeglplatformscreen.cpp  0
qeglplatformwindow.cpp  0
qevdevkeyboardhandler.cpp   0
qevdevkeyboardmanager.cpp   0
qevdevmousehandler.cpp  0
qevdevmousemanager.cpp  0
qevdevtablet.cpp0
qevdevtouch.cpp 0
qeventdispatcher_glib.cpp   0
qfbbackingstore.cpp 0
qfbcursor.cpp   0
qfbscreen.cpp   0
qfbvthandler.cpp0
qfbwindow.cpp   0
qfontconfigdatabase.cpp 0
qfontengine_ft.cpp  0
qfontenginemultifontconfig.cpp  0
qgenericunixeventdispatcher.cpp 0
qgenericunixservices.cpp0
qgenericunixthemes.cpp  0
qglxconvenience.cpp 0
qinputdevicemanager.cpp 0
qopenglcompositor.cpp   0
qopenglcompositorbackingstore.cpp   0
qopenglfunctions_4_4_compatibility.cpp  0
qopenglfunctions_4_4_core.cpp   0
qopenglfunctions_4_5_compatibility.cpp  0
qopenglfunctions_4_5_core.cpp   0
qplatformgraphicsbuffer.cpp 0
qplatformgraphicsbufferhelper.cpp   0
qsslellipticcurve.cpp   0
qsslpresharedkeyauthenticator.cpp   0
qstatusnotifieritemadaptor.cpp  0
qunixeventdispatcher.cpp0
qxcbbackingstore.cpp0
qxcbclipboard.cpp   0
qxcbconnection.cpp  0
qxcbconnection_xi2.cpp  0
qxcbcursor.cpp  0
qxcbdrag.cpp0
qxcbglintegration.cpp   0
qxcbglintegrationfactory.cpp0
qxcbimage.cpp   0
qxcbintegration.cpp 0
qxcbkeyboard.cpp0
qxcbmime.cpp0
qxcbnativeinterface.cpp 0
qxcbnativeinterfacehandler.cpp  0
qxcbscreen.cpp  0
qxcbsessionmanager.cpp  0
qxcbsystemtraytracker.cpp   0
qxcbwindow.cpp  0
qxcbwmsupport.cpp   0
qxcbxsettings.cpp   0
qxdgnotificationproxy.cpp   0
qxlibeglintegration.cpp 0
rules.c 0
scanner.c   0
state.c 0
symbols.c   0
text.c  0
types.c 0
utf8.c  0
utils.c 0
vmod.c  0
xkb-compat.c0
xkb-keymap.c0
xkbcomp.c   0
forkfd.c0,2841726619
qsharedmemory_systemv.cpp   0,5789473684
qsystemsemaphore_systemv.cpp0,78125
qsslellipticcurve_openssl.cpp   1

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] optimizing QComposeInputContext / TableGenerator?

[Paeglis Gatis]

Hi,

The idea is to move the compose file reading code out of Qt. libxkbcommon 5.0 
(released on 2014-10-18 [1]) added support
for the compose keys. I did look at the new API already in October [2]. It 
should be simple enough to remove the table generation code and use xkbcommon's 
API instead. I have not done any benchmarking because I never got around to 
finishing that patch. 

There are several projects that use xkbcommon (Wayland, GTK), so we can benefit 
from the optimizations done by others if we
use this new API. Also if somebody has suggestions for improvements, those 
should be done in [3]. 

[1] http://lists.freedesktop.org/archives/wayland-devel/2014-October/017836.html
[2] *WIP* https://codereview.qt-project.org/#/c/98062/
[3] https://github.com/xkbcommon/libxkbcommon

From: development-bounces+gatis.paeglis=theqtcompany@qt-project.org 
development-bounces+gatis.paeglis=theqtcompany@qt-project.org on behalf 
of Thiago Macieira thiago.macie...@intel.com
Sent: Monday, January 19, 2015 9:38 PM
To: development@qt-project.org
Subject: Re: [Development] optimizing QComposeInputContext / TableGenerator?

On Monday 19 January 2015 21:17:00 Giuseppe D'Angelo wrote:
  The best approach of course would be to have a OpenDesktop standard that
  allows mmapping the compose table in and using it from there. Probably not
  feasible.

 Why not?

x...@freedesktop.org. I think I can easily convince the EFL folks for this.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Jira component re-arrangements

[Paeglis Gatis]

 I would not be terribly upset if somebody that actually did work on the xcb 
 plugin stepped up and took this one :)

 I would not say that I know all parts of the XCB plugin (yet), but I guess I 
feel comfortable enough to be the default
 assignee if nobody else is volunteering.

Gatis.

From: development-bounces+gatis.paeglis=digia@qt-project.org 
[development-bounces+gatis.paeglis=digia@qt-project.org] on behalf of 
Gunnar Sletta [gunnar.sle...@jolla.com]
Sent: Tuesday, May 13, 2014 12:29 PM
To: Blasche Alexander
Cc: development@qt-project.org
Subject: Re: [Development] Jira component re-arrangements

On 13 May 2014, at 11:18, Blasche Alexander alexander.blas...@digia.com wrote:

 Hi,

 Following some discussions on this list and in Jira I have made changes to 
 Jira components. If you have a filter that explicitly mentions one of the 
 affected components, please adjust them now. Otherwise you filter may not 
 return the correct results going forward.

 1.)
 - Core: Gesture Support - Widget: Gesture Support (rename)
 - New owner for above component: Marc Mutz

 For more details see QTJIRA-255

 2.)
 Following new components have been created:
 GUI: Windows integration - owner: Friedemann Kleint
 GUI: X11 (xcb) integration - owner: Gunnar Sletta

I would not be terribly upset if somebody that actually did work on the xcb 
plugin stepped up and took this one :)

 GUI: OS X (cocoa) integration - owner: Morton Sorvig

 For more details see QTJIRA-256

 3.)
 - Core: Event System - Core: Event loop (rename)

 For more details see QTJIRA-257

 4.)
 - GUI: Input methods -GUI: Complex Input methods (rename)
 - GUI: Basic Input System (keyboard, mouse, touch) (created)
 - New owner for Basic Input System: Gunnar Sletta

 For more details see QTJIRA-258

 --
 Alex

 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qt5.3 beta - xkbcommon: ERROR

[Paeglis Gatis]

The latest change in that area was 
https://codereview.qt-project.org/#change,79342 , it requires re-configuring Qt.
Did you do that? Also when using the bundled version of libkxbcommon, make sure 
that in config.summary you 
get:

xkbcommon .. yes (bundled copy, xkb-config-root some_path_here)


From: development-bounces+gatis.paeglis=digia@qt-project.org 
[development-bounces+gatis.paeglis=digia@qt-project.org] on behalf of 
Martin Koller [kol...@aon.at]
Sent: Tuesday, March 25, 2014 9:15 PM
To: development@qt-project.org
Subject: [Development] qt5.3 beta - xkbcommon: ERROR

I have installed qt5.3 pre21.1 today from openSuse repo.
Now whenever I start a simple Qt5 app, I get:

xkbcommon: ERROR: failed to add default include path auto
Qt: Failed to create XKB context

and I can not enter any text.
any idea what the problem could be ?
Is than an openSuse problem and should be reported there ?

--
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail
/\- against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Wiki: 3rd party in Qt

[Paeglis Gatis]

Regarding the xkbcommon, we are bundling 0.2.0, not 0.3.1.
I am waiting for the next release of xkbcommon, which will provide few new 
functions that I want
to use in the xcb platform plugin. That is when I am planning to update the 
bundled version as well.

Gatis.


From: development-bounces+gatis.paeglis=digia@qt-project.org 
[development-bounces+gatis.paeglis=digia@qt-project.org] on behalf of Liang 
Qi [cavendish...@gmail.com]
Sent: Wednesday, November 20, 2013 3:03 PM
To: development@qt-project.org
Subject: [Development] Wiki: 3rd party in Qt

Hi, all,

I just spent some time to gather the information of 3rd party in Qt(5).

http://qt-project.org/wiki/Third_Party_In_Qt

Please help to update or maintain it.

Maybe there is a legal issue about wintab, more details in their webpage:
http://www.pointing.com/Wintab.html

Regards,
Liang

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Changing keyboard layouts in Qt 5.1 apps with GNOME

[Paeglis Gatis]

Its probably because of the issue described in:

https://bugreports.qt-project.org/browse/QTBUG-30911
https://bugs.freedesktop.org/show_bug.cgi?id=23202

Switching between layouts should work in all cases, but adding a new layout 
might not be seen until the application is restarted.

From: development-bounces+gatis.paeglis=digia@qt-project.org 
[development-bounces+gatis.paeglis=digia@qt-project.org] on behalf of 
Thiago Macieira [thiago.macie...@intel.com]
Sent: Saturday, August 31, 2013 6:35 PM
To: development@qt-project.org
Subject: Re: [Development] Changing keyboard layouts in Qt 5.1 apps with
GNOME

On sábado, 31 de agosto de 2013 14:51:58, Petko Ditchev wrote:
   I need some help troubleshooting a problem I've been having : for a
 week now (I think since some updates to the keyboard layout settings in
 gnome) I can't change the keyboard layout in QtCreator (built with
 Qt5.1) and in my app that is on the same lib . Otherwise everything's ok
 , but Qt5.1 apps stick with the layout they are launched with .
   I'm sending this to both lists because the bug affects GNOME , but not
 Unity , and it affects Qt5.1 , but not Qt4 .

Can you provide us with the output of setxkbmap -print before and after the
keyboard change? It would be useful to get the xev output for a keystroke that
changed too (before and after).

Finally, can you make the same test by switching keyboard layouts with
setxkbmap?

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Why I can't use ibus Input Method for type Chinese character?

[Paeglis Gatis]

Did you set the environmental variable to QT_IM_MODULE=ibus?

From: development-bounces+gatis.paeglis=digia@qt-project.org 
[development-bounces+gatis.paeglis=digia@qt-project.org] on behalf of 
Yuchen Deng [loa...@gmail.com]
Sent: Saturday, May 11, 2013 2:54 PM
To: development
Subject: [Development] Why I can't use ibus Input Method for type Chinese 
character?

Hi, there!
I want help because I can't input any Chinese character for Qt5 based 
application, include QtCreator when build with Qt5.1.

I just know I need build D-Bus for plugins/platforminputcontexts/ibus.
Then I did, and I can sure QtCreator loaded the ibus plugins.
Here is the full log: http://pastebin.mozilla.org/2393461

But I still can't input Chinese in QtCreator, because ibus tell me there `No 
input window`.

I asked in #qt, #qt-labs, and #qt-cn, but seems nobody know why and how.
So I think it's maybe is a bug.
Any comments are welcome.
Help needed. thanks a lot!

--
Best Regards
Yuchen
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Why I can't use ibus Input Method for type Chinese character?

[Paeglis Gatis]

 Why Qt5 need it?

In Qt5 this variable is read to determine which input context plugin to use, by 
default it is set to
compose. [1] Other keys are ibus and maliit.

[1] https://codereview.qt-project.org/#change,51555

From: Yuchen Deng [loa...@gmail.com]
Sent: Saturday, May 11, 2013 4:18 PM
To: Paeglis Gatis
Cc: development
Subject: Re: [Development] Why I can't use ibus Input Method for type Chinese 
character?


2013/5/11 Paeglis Gatis 
gatis.paeg...@digia.commailto:gatis.paeg...@digia.com
QT_IM_MODULE=ibus

I did not set this environment variable. and I can sure after set this 
environment variable to ibus, then the issue just gone!
But why? no need this environment, all other applications works fine with ibus.
Why Qt5 need it?


--
Best Regards
Yuchen
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] include X11/keysym.h

[Paeglis Gatis]

It is a leftover, I have submitted a change: 
https://codereview.qt-project.org/#change,52599

From: development-bounces+gatis.paeglis=digia@qt-project.org 
[development-bounces+gatis.paeglis=digia@qt-project.org] on behalf of 
Thiago Macieira [thiago.macie...@intel.com]
Sent: Thursday, March 28, 2013 4:02 PM
To: development@qt-project.org
Subject: Re: [Development] include X11/keysym.h

On quinta-feira, 28 de março de 2013 13.35.22, Thomas Senyk wrote:
 Question on the side: This is a commit for stable, right?
 ... It can be considered a build-bug-fix... or not?

Stable, it's a build fix.
--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] input method support in Qt5 (linux)

[Paeglis Gatis]

After  looking at Qt4 / Qt5 source code and doing some internet search I see 
that ibus plugin has become a part of Qt, where in Qt4 it was a separate plugin 
hosted somewhere else..

Qt4 offered two options XIM and IBUS, selectable by using 'qtconfig' tool, 
currently Qt5 has support only for ibus as input method framework (IMF) , which 
does look like a great IM framework, but is it complete enough to be the only 
available option in Qt for desktop?

It's very important to the Qt project that input works well for all users 
without exhausting tweaking, but at the present it is quite frustrating with 
ibus-setup GUI tool which almost never does what you tell it to do.

It seems that the latest ibus release supports good additions like:

- Improve IME switch UI
- Integrate IME and XKB keyboard layouts. Now ibus can manage both IME and XKB 
layouts.
etc.

AFAIK linux distros doesn't ship by default this version yet.

I don't know if there has been any decision regarding this.. I was wondering if 
we should bring back xinput support in XCB plugin? [1]

[1] http://lists.freedesktop.org/archives/xcb/2013-January/008059.html
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development