[Development] important: upcoming rename of _qpa.h to _p.h
Samuel Rødal
samuel.rodal at nokia.com
Fri Apr 20 09:02:11 CEST 2012
On 04/18/2012 04:03 PM, ext Girish Ramakrishnan wrote:
> 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.
Sounds good to me.
> 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).
Agreed, the ideal is to hide this from application developers.
> 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>
Yeah, I can get behind using this type of include. A good reason why the
_qpa.h suffix should be removed, as
<QtGui/qpa/qplatformbackingstore_qpa.h> looks quite ugly.
> 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)
Not sure about the latter, it would include widget headers even for a
platform plugin that might not want to link against widgets. Would
<QtGui/QPA> and <QtWidgets/QPA> as separate includes be an option?
> 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.
Yep.
> 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.
Good points. BC might not be that important, not sure Jeremy's scenario
of binary only platform plugins will become an issue on platforms where
people build their own Qt.
--
Samuel
More information about the Development
mailing list