2010/7/18 Julian Bäume <julian@svg4all.de>
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.

It's not really a problem, but a feature. As we know, plugins can be loaded and unloaded. But we need to have a list of all available components and models (in order to present a list of them to the user), so some plugins should be marked as "to be loaded by default".

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.

I see two possible solutions to this:
- either have separate .desktop files for each kdevplatform version, for each plugin (many files, might get ugly), and install the one corresponding for the found kdevplatform version

- generate the .desktop files when configuring the sources, automatically. This can be done by a simple variable substitution. The only problem I see with this is making the implementation really system-independent. Probably by using only cmake, this kind of processing can be implemented.

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.

Yes, I've seen this, too. Maybe we should add the links to the wiki, for example:
>  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.

Don't forget the "backend": the simulator, math engine, and maybe the models (these could be considered together with the components).
>  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.

Plugins registering to other plugins? Sounds interesting but I'm not sure it wouldn't complicate things too much. It should be investigated.

Currently the SimulationManager is implemented, where all the simulation related factories can be registered. Maybe later it would be better to have this manager in a plugin? Or split it up in smaller pieces? For now I just want something to work; reorganizing the code shouldn't be such a big problem.

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

In my opinion, the exact way of implementation should be tested. If the development / deployment isn't painful (see discussions on IRC), then it should be good enough. The main idea is to separate things in plugins.

Documenting everything on the wiki would be great. Also I'm thinking of writing some programming guide in doxygen, as it's done for eigen, see for example this page:


This way the documentation would be near the code, and it would be simpler to maintain.

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.

When a plugin is unloaded, it should unregister all its factories. At initialization, at most the plugins should be loaded, but the registering/unregistering should be done by the plugins. If the circuit/flowcode/code are separate plugins, then the component plugins should depend on them. I'm not sure if this functionality works in kdevplatform, currently.
 bye then 

This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
Ktechlab-devel mailing list