[Qt-interest] About Plugin Architecture in QT

[Andreas Pakulat]

On 30.04.09 19:26:57, Manuel Fiorelli wrote:
> 2009/4/29 David Boddie <david.boddie at nokia.com>:
> > Reading this, I am reminded of GCF:
> >
> > http://www.vcreatelogic.com/oss/gcf/index.html
> >
> > I don't know if it corresponds closely to what you are looking for, but
> > you might find it interesting, anyway.
> 
> In my opinion QPlugin is a wonderful tool for "simple tasks" such as
> support arbitrary codec, DB drivers, etc..., but it is too low level
> if we want to develop an extensible application like Eclipse.
> 
> I know that Qt-Creator is based on plugins, like Eclipse, so I suppose
> that Qt Creator uses a plugin architecture developed internally by Qt
> Software.

No, Qt Creator uses plain old Qt plugins, but of course provides some
extra API and a hosting shell which loads the plugins. Additionally
interfaces are provided that plugins can implement to extend the core
functionality. Thats basically what eclipse has, except its not such a
monster and not so overly complex.
 
> Is there any chance that Qt will provide native support for such an
> architecture?

They already do, its called Qt Creator and is Open source also.

> Binary compatibility in C++ is an hard matter (even if Qt has a really
> clean policy about it), thus the architecture should support also the
> notion of source component, that is to say a package which may be
> built on the host machine with the current configuration in a really
> simple way (think about RPM and SRPM).

So you want to throw some source code at the hosting application and it
should build it on the fly? Hmm, that would force each such application
to make sure a proper build environment is available, not sure thats
very good.

Maybe you should rather seek in the area of scripting languages like
Python or Ruby and the related Qt bindings. Those don't need to care
about BC as long as the API is stable and can be loaded without any
compilation.

> 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++).

I don't know XUL, but both the eclipse and the KDE framework for GUI
merging are far from perfect. They both have quite some drawbacks (for
example its not possible to restrict on what actions a given plugin
supplies in an easy way) and are both relatively complex. That said I
don't think services are making things any easier, except that debugging
why/how a given action doesn't show up is easier usually.

Andreas

-- 
Your business will go through a period of considerable expansion.