[Development] important: upcoming rename of _qpa.h to _p.h

[Girish Ramakrishnan]

Hi,

On Wed, Apr 18, 2012 at 3:28 AM,  <lars.knoll at nokia.com> wrote:
> Still the QPA headers are sort of a different beast from private headers.
> While I don't want to promise anything on them yet (I think we might want
> to keep SC and BC for them in patch level releases), they are supposed to
> be used by third parties and supported. Our private headers are not
> supported.
>

Fair enough. Can we agree that:
1. _qpa suffix serves no purpose. qplatform prefix already says that
it's qpa specific.
2. We don't want the 'we mean it' header in the qpa files since these
files are meant for third party plugin authors.

Here's my opinion: Whatever 'new' convention we come up with will
require educating the masses. The number of plugin authors can be
counted, what 50? The number of Qt app developers are possibly in tens
of thousands. We have to now teach these tens of thousands that
whatever convention we come up with these qpa files is not for their
use. I can count the number of plugin authors who work on QPA but not
on Qt code itself to exactly two (that's the android and ios port, but
for all I know they hack on Qt too).

Since there's been no proposal, here's an alternate proposal:
1. We drop _qpa completely. So, it would become qplatformbackingstore.h
2. We teach syncqt that qplatform* is special and we move them all to
a special qpa/ directory. So, instead of #include
<QtGui/private/qplatformbackingstore.h>, it will be #include
<QtGui/qpa/qplatformbackingstore.h>
3. We teach syncqt to create <QtGui/QPA> or #include <QPA> headers. (I
think we need the latter since qpa headers are not restricted to gui)
4. We teach the world that qpa is not meant for apps.
5. Add a more benign header pointing out the fact that these files are
qpa files.
6. Rename the handle() to platformXXX() since it's easy to educate
that anything that has platform in it is out of reach of app
developers.

What follows is an OT/rant and not relevant to the discussion as such:
'plugin' usually refers to things add capabilities to an existing
thing. qpa plugins are not really plugins, they are the thing itself.
Without qpa plugin, Qt doesn't do anything. That's not a plugin. It is
well and truly a part of Qt. As opposed to codec plugins - Qt will run
just fine without those codec plugins. I would argue that QPA
"plugins" are very much implementation detail, they are not part of Qt
API and we really do mean it that the headers can change any time
(hence the 'we mean it' header). I fail to see why we want BC with QPA
plugins. While this is a noble notion, I don't see any real benefit.
QPA code are not plugins, it's Qt itself. The dynamic loading of QPA
is an implementation detail/convenience.

Girish