[Development] qpa api - current status

[Samuel Rødal]

On 05/25/2012 06:15 PM, ext Girish Ramakrishnan wrote:
> Hi,
> 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
> <QtGui/qpa/qplatformbackingstore.h>
> 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
> developers.
> 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.

--
Samuel