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