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

[lars.knoll at nokia.com]

Proposal sounds ok to me as well. If someone still has concerns, please
speak up.

Cheers,
Lars

On 4/20/12 9:02 AM, "ext Samuel Rødal" <samuel.rodal at nokia.com> wrote:

>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
>_______________________________________________
>Development mailing list
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development