KDevelop4 architecture overview

[Andreas Pakulat]

On 16.03.07 22:28:10, Alexander Dymo wrote:
> Hope the attached document helps. By all means, please bug me if something
> is wrong/missing/unclear in the document.

I'll bug you right away :)

> 5.3.1 To declare extension interface:
> - Create an abstract class
> - Include <iextension.h>
> - Add following macroses to the header file with a class:
>     KDEV_DECLARE_EXTENSION_INTERFACE( KDevelop, IMyInterface, "org.kdevelop.IMyInterface")
>     Q_DECLARE_INTERFACE( KDevelop::IMyInterface, "org.kdevelop.IMyInterface" )

This is not 100% right, you can use Q_DECLARE_EXTENSION_INTERFACE for
any interfaces that do not live in a namespace. If you use that you
won't need the Q_DECLARE_INTERFACE as that is used inside
Q_DECLARE_EXTENSION_INTERFACE anyway.

> 5.3.2 To implement extension interface:
> - Create a plugin as usual
> - Subclass it from your interface
> - Use Q_INTERFACES macro in class declaration
> - reimplement QStringList IPlugin::extensions() method
> - declare in plugin's .desktop file:
>     X-KDevelop-Interfaces=IMyInterface

This is not enough, for one you need a factory that can create an
extension from a plugin pointer for each interface the plugin
implements. Also the plugin needs to implement
registerExtensions/unregisterExtensions. The factories can be created
via macros (see the iplugin.h header), however for the
register/unregister functions those need to be implemented by hand (its
not that hard, see existing plugins like the qmake manager) for plugins
that implement more than one interface. Also a plugin that implements
interface Foo and Foo is subclasses from Bar it also implements Bar and
thus it implements 2 interfaces... 

I'm planning to make all this a bit easier with some C++ template code
that David posted in february. I just didn't get around to look at it
yet. I hope then we have something as simple as

KDEV_REGISTER_INTERFACE(plugin,interface)
KDEV_REGISTER_INTERFACE(plugin,interface)
and
KDEV_DECLARE_EXTENSION_INTERFACE(interface) (without using Q_DECLARE...
for non-namespaced classes).

I hope I get around to doing that in the upcoming week (no time during
the weekend).

> 5.3.4 To set a dependency between plugins:
> - Set the list of required interfaces in plugin's .desktop file
>     X-KDevelop-IRequired=IMyInterface,IMyOtherInterface
> It is not possible to set direct inter-plugin dependencies. The plugin shall never expect another
> plugin, it shall only expect an interface.

> The project management infrastructure can be represented with following diagram (use fixed font to see it):
> 
>                               |----------|       |---------------------|
>                         |---->| IProject |------>| IProjectFileManager |
>                         |     |----------|       |---------------------|
>                         |
> |--------------------|  |     |----------|       |---------------------|
> | IProjectController |------->| IProject |------>| IProjectFileManager |
> |--------------------|  |     |----------|       |---------------------|
>           |             |
>           |             |     |----------|       |---------------------|
>           |             |---->| IProject |------>| IProjectFileManager |
>           |                   |----------|       |---------------------|
>           |
>           |    |--------------|
>           |--->| ProjectModel |
>                |--------------|

Actually there's a link missing: from ProjectModel to project. This is
done by having a pointer to the IProject in each item in the projectmodel.

Another small detail is that there's only 1 plugin loaded for each type
of project, i.e. only 1 qmake manager. This also means that plugins
either have to know how to handle multiple projects or work totally
without any project at all. A plugin that only works on 1 project is
broken.

> KDevelop supports the notion of "current project" (the one which is currently selected) in the
> project management view). But plugins are encouraged to not depend on it. The selection might be
> empty or project management view might be closed at any time.
 
I still have hopes that we can remove this "current project" thing,
because its only used for one thing at the moment: 
the settings stuff, which is supposed to be reworked anyway

Then the projectmanager might still expose actions that work on the
"selected" project, however the project manager knows exactly what
project is current and can take proper action if no project is selected.

> Once the factory is ready, it has to be added to the UiController using
> IUiController::addToolView() method.
> It is not absolutely necessary for a plugin to remove or delete toolview factory. UiController will
> delete them all upon unload.

Uhm, actually the plugin should not delete the factory as that will
result in a crash on kdevelop closing. (At least when the plugin keeps a
pointer to the factory)

Andreas

-- 
There was a phone call for you.