[Development] important: upcoming rename of _qpa.h to _p.h

[Jeremy KATZ]

On 04/18/2012 04:03 PM, ext Girish Ramakrishnan wrote:
> Hi,
>
...
> 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.
>

I think the word you're looking for is backend. QPA is a (partial) port 
of Qt, and dynamically loaded QPA modules implement a backend for the 
relevant portion.

BC is relevant because the backend a particular system uses may not be 
available with upstream Qt, while the system may otherwise be compatible 
with a widely used and hence upstream build. I think of this as 
equivalent to a hardware vendor providing a binary-only Linux kernel 
module. If you have to wait for the vendor to provide the complete 
kernel, delivery of unrelated fixes and features suffer.

That said, I suspect that most implementors of custom backends are going 
to be dealing with embedded devices where they will not want to support 
upstream builds or upgrades asynchronous to their release cycle. 
Offering a lengthy BC promise for this case doesn't have much value. 
Compatible patch level releases sound like a nice target if they don't 
involve excessive pain.

Jeremy