Re: [Development] A simple analysis of apps using qtbase's private headers

[Sune Vuorela]

On 2016-02-02, Liang Qi  wrote:
> Above three are not applications, they must be input context plugin of Qt,
> just like ibus in
> https://github.com/qtproject/qtbase/tree/5.5/src/plugins/platforminputconte=
> xts/ibus
> . Normally every input method software could/should have one of this kind
> of plugin for Qt 5, so there is no question when they use private headers.

There is two ways to fix the usage of private headers in external
things.

1) is to stop using them
2) is to promote more private api to public api.

I do think that one should consider it for the bits needed to make input
methods.

Really. Public private api is bad. It should really not exist. It harms
our "We promise source and binary compatibility" promises, because it is
full of 'except ...' .

We should head towards not have any public private api.

/Sune

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

Re: [Development] A simple analysis of apps using qtbase's private headers

[Liang Qi]

On 22 January 2016 at 04:15, Lisandro Damián Nicanor Pérez <
perezme...@gmail.com> wrote:

> The following three have something in common: they are all apps coded for
> Chinese people. I've been told that they need QPA's private stuff in order
> to
> have proper input systems, but I haven't checked.
>
> * fcitx-qt5 1.0.5
> * gcin 2.8.4
> * hime 0.9.10
>

Above three are not applications, they must be input context plugin of Qt,
just like ibus in
https://github.com/qtproject/qtbase/tree/5.5/src/plugins/platforminputcontexts/ibus
. Normally every input method software could/should have one of this kind
of plugin for Qt 5, so there is no question when they use private headers.

Regards,
Liang

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

[Development] A simple analysis of apps using qtbase's private headers

[Lisandro Damián Nicanor Pérez Meyer]

I did a **very** simple analysis of apps packaged in Debian using qtbase's 
private headers. My main concern was to see if we (Debian) can avoid having to 
rebuild them every time we push a new version of Qt to our archive.

What I've found seemed interesting so I decided to share it here.

The following three have something in common: they are all apps coded for 
Chinese people. I've been told that they need QPA's private stuff in order to 
have proper input systems, but I haven't checked.

* fcitx-qt5 1.0.5
* gcin 2.8.4
* hime 0.9.10

If people go to the extent of using private headers for this maybe it's a very 
good reason to (somehow) make that part of the API public. It might make a 
difference for chinese coders.

--8<--

The following three seems to be using at least qpa/qplatformtheme.h

* KDE's frameworkintegration 5.16.0
* libqtxdg 1.3.0
* lxqt-qtplugin 0.10.0

Maybe for being able to create it's own theme?

--8<--

And the rest for various reasons:

* KDE's kdeclarative 5.16.0: code says to use QQuickImageProvider

* KDE's kwin 5.4.3: qpa/qwindowsysteminterface.h

* gammaray 2.4.0 I guess it needs to get into internal stuff.

* musescore 2.0.2 An interesting false positive. It embeds Qt's code without a 
namespace so the resulting symbols files get catched by our tools and confuse 
them.

* qtcurve 1.8.18: private/qwidget_p.h (no further digging)

* calibre 2.48.0: quite a lot of stuff, just saw it and left it there.


That's all. I really hope someone finds it interesting.














-- 
Never attribute to malice that which is adequately explained by stupidity.
  http://en.wikipedia.org/wiki/Hanlon's_razor

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development