[Qt-interest] About Plugin Architecture in QT

[Prashanth Udupa]

> In my opinion QPlugin is a wonderful tool for "simple tasks" such as

> support arbitrary codec, DB drivers, etc..., 

Yes; QPlugin simplifies the task of handling extensions to known types in an application. If an application architecture is designed to accept, db-codecs, styles, animators,... basically objects that implement specific types of interfaces; then QPlugin is very simple to use and productive. But if we need an application architecture that can support both known and unknown types, then we need to build more stuff on top of QPlugin.

> but it is too low level
> if we want to develop an extensible application like Eclipse.

That's right. GCF is intended to solve this problem. It provides a high-framework to create components (shared objects / dll files basically) and a component-loading mechanism that will load resources provided by the plugin by parsing a XML file and "fit" the resources into the application's main-window container. Once loaded components can search for objects (provided by other components) that implement one or more interfaces and make use of functionality off erred by other components. In effect it solves several core issues

* Loading of components
* GUI Merging
* Functionality discovery / use. 

GCF encourages the use of "interfaces" as opposed to "classes". That, in a way, fosters reuse and backward compatibility., 

Apart from the core issues above, it offers a bunch of peripheral things like

* Inter-Process-Communication: Signal/Slot connection between objects in separate processes/systems, calling methods on remote objects. GCF internally does all the marshalling/unmarshalling tasks.
* Automatic Updater framework: A framework for composing updates, hosting them and having applications automatically download and install them.
* Generic Logging functionality: A simple framework for creating log files and populating them with log messages.

> It is unclear to me if the architecture should also provide a special
> support for GUI merging (like XUL overlays in Mozilla Platform) or if
> the GUI should be extended through services (implemented in C++).

GUI Merging via XML and via C++ code; both have their pluses and minuses. GCF supports both types of merging. The XML based GUI merging solves quite a few problems

* Trigger and Toggle slot connection - It is possible to specify what slot that needs to be called in what object; in the XML file itself
* Sharing of actions - It is possible to share a single QAction among different components. When triggered/toggled all the receivers get called
* Context based actions - Suppose that a single QAction is shared among different components, its signals call only the slots of receives in active components. If none of the receives are owned by active components; then the action is disabled (by default); can be hidden if needed.
* Nested menus: Using the XML file it is possible to nest actions into menus/submenus etc..
* Actions created via the GUIXML file can be controlled via code as well. So the C++ code still has total control over the action.

The main aim of GCF is to provide a basic application architecture that can be further customized and fine-tuned for specific application purposes. There are a few open-source applications/frameworks that are making of GCF for this exact purpose.

[1] http://code.google.com/p/qtsf/
[2] http://svn.codingteam.net/visionapplication/trunk/

/ Prashanth