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