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