[Development] qpa api - current status
samuel.rodal at nokia.com
Tue May 29 08:19:34 CEST 2012
On 05/25/2012 06:15 PM, ext Girish Ramakrishnan wrote:
> Here's the current status of the proposed plan of action for QPA api.
> 1. We drop _qpa completely. So, it would become qplatformbackingstore.h
> Status: Done
> 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
> Status: Done
> 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)
> Status: I haven't created the master headers. I don't think it's
> important (will be good to have though).
> 4. We teach the world that qpa is not meant for apps.
> Status: Doc team task ;) But all qpa classes are now marked with \group qpa
> 5. Add a more benign header pointing out the fact that these files are
> qpa files.
> Status: Done. qpa headers files don't have the "we mean it" header
> anymore. Please use the new header for qpa headers which explicitly
> says using api there may result in code breakage in the future.
> 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
> Status: In progress, I am atm, marking handle() as obsolete and as an
> alias to platformXXX().
> The only remaining _qpa.h files are (they don't follow qplatform* convention):
> 1. qgenericplugin_qpa.h. AFAICT, this doesn't have to do with QPA at
> all. So, we can either make it public or private.
Yep, I guess this API isn't likely to change much.
> 2. qwindowsysteminterface_qpa.h. This is a little tricky. We have
> qtestlib using it at this point because this is the way to send events
> to Qt. The API looks OK, can we make this public?
Not sure the API is stable enough for that. qtestlib still lives in
qtbase so there's less of an issue there.
More information about the Development