[Ktechlab-devel] Loading all the component and model plugins

[Julian Bäume]

Hey,
I needed some time to think about all this, but I think, it's now time to 
share some thoughts ;)

On Thursday 15 July 2010 09:47:57 Zoltan Padrah wrote:
> The problem that should be discussed is related to the plugin-loading
> mechanism of kdevplatform: the plugins are loaded and unloaded
> automatically.
If there is really a problem with KDevPlatform-plugin-handling, we should 
discuss these with the kdevelop-team. I'm sure, we can find a solution 
together with them.

The main issue, I see at the moment, is the versioning of the plugins. We need 
to keep the version-numbers in sync with the KDevPlatform-Version, we are 
using. This could differ from developer to developer and this is annoying. I 
experimented to solve this for us with some cmake-magic, but haven't tried to 
hard and didn't find a good solution, so far. Anyway, it should be possible to 
generate the version-string in the desktop file, depending on the KDevPlatform 
version installed. Quite a few version bumps didn't affect our plugins during 
the last times and so this could save us some work. OTOH it doesn't solve API-
changes, but we would have to deal with them anyway.

Concerning loading of plugins, there are 2 different types of plugins in 
kdevplatform. Plugins of the "global" type show up in the modules-list in the 
application settings. You can load and unload these on demand as a user. In 
KTechLab the circuit plugin is one of these. Later there will be the flowcode 
plugin and maybe some micro-controller-plugin. Then there are plugins of 
"project" type. These are always loaded and these won't show up in the 
modules-list in the settings. The project-plugins only work with some project 
being loaded and active.
This is at least, what I remember from the KDevPlatform documentation.

>  We need all circuit/component/... plugins to be loaded. In order to
> achieve this, I'd like to define an interface that will be implemented by
> the needed plugins, and at startup ktechlab should ask for all the plugins
> implementing that interface (and keep a list of them?).
My understanding of KTechLab looks like this: There is the main application 
doing nothing but providing space to place toolboxes, edit-windows and all 
kind of tools needed for development. Then there are the "global" plugins, 
which define the capabilities of KTechLab. From the kde3-version point-of-
view, these are: Circuits, FlowCode and MCU-Programming. (Where MCU is limited 
to PIC only.) Then there are plugins that support those activities, like 
components (to be placed in a circuit file or on FlowCode documents), routing 
(also circuits and FlowCode) and so on.

>  In my view, the plugins should only register factories; themself shouldn't
> implement any other functionalities. For example one plugin could register
> factories for a transistor and for a model for the transistor.
Agreed. The plugin itself knows which type of objects it can provide factories 
for. So there's a component-plugin providing factories for graphical-
representations and models of transistors. It's intended to be used in circuit 
files. It could then register the factories at the circuit plugin, so this one 
keeps track of all plugins, that are capable of extending circuit files. The 
plugin providing some special conditional-component for the FlowCode plugin 
registeres itself at the FlowCode plugin. Interfaces for the components can be 
shared, this way (like it was in the KDE3-version) and it will be scalable  by 
writing more plugins and distribute them.

Zoltan, do you agree on that architecture? Then I am going to write that down 
in the wiki to have all this documented in a central place (beside the ML). I 
had most of this in mind for a long time, now, but didn't document it, yet. 
This reminds me of starting to do so :S

I'm sure there will be minor problems implementing all this. Since it's 
possible to unload the global plugins via the settings, what happens to the 
plugins providing factories for these? The FlowCode-components won't be 
needed, when FlowCode is deactivated and they would register themselves during 
initialization and not, when the FlowCode plugin is loaded. The KDevPlatform 
sessions would make it possible to work on different projects with different 
plugins loaded. This way one could reduce memory usage and we should respect 
that with the plugins we load. But I think all these issues can be solved and 
we should continue this way.

bye then
julian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/ktechlab-devel/attachments/20100718/eae98e23/attachment.sig>