I needed some time to think about all this, but I think, it's now time to
share some thoughts ;)
If there is really a problem with KDevPlatform-plugin-handling, we should
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
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 toMy understanding of KTechLab looks like this: There is the main application
> 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?).
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.
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