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

Sun Jul 18 09:47:36 UTC 2010

Hi,

2010/7/18 Julian Bäume <julian at svg4all.de>

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

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:

http://www.kdevelop.org/mediawiki/index.php/Extension_Interfaces_and_Plugins

> >  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:

http://eigen.tuxfamily.org/dox/TutorialCore.html

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

julian
>
>
Zoltan

>
> ------------------------------------------------------------------------------
> 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
> Ktechlab-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/ktechlab-devel/attachments/20100718/b14f48f8/attachment.html>