On 04/18/2012 04:03 PM, ext Girish Ramakrishnan wrote: > Hi, > > On Wed, Apr 18, 2012 at 3:28 AM, <lars.kn...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
