Hi,<br><br><div class="gmail_quote">2010/7/18 Julian Bäume <span dir="ltr"><<a href="mailto:julian@svg4all.de">julian@svg4all.de</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hey,<br>
I needed some time to think about all this, but I think, it's now time to<br>
share some thoughts ;)<br>
<div class="im"><br>
On Thursday 15 July 2010 09:47:57 Zoltan Padrah wrote:<br>
> The problem that should be discussed is related to the plugin-loading<br>
> mechanism of kdevplatform: the plugins are loaded and unloaded<br>
> automatically.<br>
</div>If there is really a problem with KDevPlatform-plugin-handling, we should<br>
discuss these with the kdevelop-team. I'm sure, we can find a solution<br>
together with them.<br></blockquote><div><br></div><div>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".</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
The main issue, I see at the moment, is the versioning of the plugins. We need<br>
to keep the version-numbers in sync with the KDevPlatform-Version, we are<br>
using. This could differ from developer to developer and this is annoying. I<br>
experimented to solve this for us with some cmake-magic, but haven't tried to<br>
hard and didn't find a good solution, so far. Anyway, it should be possible to<br>
generate the version-string in the desktop file, depending on the KDevPlatform<br>
version installed. Quite a few version bumps didn't affect our plugins during<br>
the last times and so this could save us some work. OTOH it doesn't solve API-<br>
changes, but we would have to deal with them anyway.<br></blockquote><div><br></div><div>I see two possible solutions to this:</div><div>- 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</div>
<div><br></div><div>- 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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Concerning loading of plugins, there are 2 different types of plugins in<br>
kdevplatform. Plugins of the "global" type show up in the modules-list in the<br>
application settings. You can load and unload these on demand as a user. In<br>
KTechLab the circuit plugin is one of these. Later there will be the flowcode<br>
plugin and maybe some micro-controller-plugin. Then there are plugins of<br>
"project" type. These are always loaded and these won't show up in the<br>
modules-list in the settings. The project-plugins only work with some project<br>
being loaded and active.<br>
This is at least, what I remember from the KDevPlatform documentation.<br></blockquote><div><br></div><div>Yes, I've seen this, too. Maybe we should add the links to the wiki, for example:</div><div> </div><div><a href="http://www.kdevelop.org/mediawiki/index.php/Extension_Interfaces_and_Plugins">http://www.kdevelop.org/mediawiki/index.php/Extension_Interfaces_and_Plugins</a></div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> We need all circuit/component/... plugins to be loaded. In order to<br>
> achieve this, I'd like to define an interface that will be implemented by<br>
> the needed plugins, and at startup ktechlab should ask for all the plugins<br>
> implementing that interface (and keep a list of them?).<br>
</div>My understanding of KTechLab looks like this: There is the main application<br>
doing nothing but providing space to place toolboxes, edit-windows and all<br>
kind of tools needed for development. Then there are the "global" plugins,<br>
which define the capabilities of KTechLab. From the kde3-version point-of-<br>
view, these are: Circuits, FlowCode and MCU-Programming. (Where MCU is limited<br>
to PIC only.) Then there are plugins that support those activities, like<br>
components (to be placed in a circuit file or on FlowCode documents), routing<br>
(also circuits and FlowCode) and so on.<br>
<div class="im"><br></div></blockquote><div> </div><div>Don't forget the "backend": the simulator, math engine, and maybe the models (these could be considered together with the components).<br></div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> In my view, the plugins should only register factories; themself shouldn't<br>
> implement any other functionalities. For example one plugin could register<br> > factories for a transistor and for a model for the transistor.</div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Agreed. The plugin itself knows which type of objects it can provide factories</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> for. So there's a component-plugin providing factories for graphical-</blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> representations and models of transistors. It's intended to be used in circuit </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
files. It could then register the factories at the circuit plugin, so this one<br>
keeps track of all plugins, that are capable of extending circuit files. The<br>
plugin providing some special conditional-component for the FlowCode plugin<br>
registeres itself at the FlowCode plugin. Interfaces for the components can be<br>
shared, this way (like it was in the KDE3-version) and it will be scalable by<br>
writing more plugins and distribute them.<br></blockquote><div><br></div><div>Plugins registering to other plugins? Sounds interesting but I'm not sure it wouldn't complicate things too much. It should be investigated. </div>
<div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Zoltan, do you agree on that architecture? Then I am going to write that down<br>
in the wiki to have all this documented in a central place (beside the ML). I<br>
had most of this in mind for a long time, now, but didn't document it, yet.<br>
This reminds me of starting to do so :S<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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:</div><div><br></div><div><a href="http://eigen.tuxfamily.org/dox/TutorialCore.html">http://eigen.tuxfamily.org/dox/TutorialCore.html</a></div>
<div><br></div><div>This way the documentation would be near the code, and it would be simpler to maintain.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
I'm sure there will be minor problems implementing all this. Since it's<br>
possible to unload the global plugins via the settings, what happens to the<br>
plugins providing factories for these? The FlowCode-components won't be<br>
needed, when FlowCode is deactivated and they would register themselves during<br>
initialization and not, when the FlowCode plugin is loaded. The KDevPlatform<br>
sessions would make it possible to work on different projects with different<br>
plugins loaded. This way one could reduce memory usage and we should respect<br>
that with the plugins we load. But I think all these issues can be solved and<br>
we should continue this way.<br></blockquote><div><br></div><div>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.</div>
<div> </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> bye then </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888">julian<br>
</font><br></blockquote><div><br></div><div>Zoltan</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">------------------------------------------------------------------------------<br>
This SF.net email is sponsored by Sprint<br>
What will you do first with EVO, the first 4G phone?<br>
Visit <a href="http://sprint.com/first" target="_blank">sprint.com/first</a> -- <a href="http://p.sf.net/sfu/sprint-com-first" target="_blank">http://p.sf.net/sfu/sprint-com-first</a><br>_______________________________________________<br>
Ktechlab-devel mailing list<br>
<a href="mailto:Ktechlab-devel@lists.sourceforge.net">Ktechlab-devel@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/ktechlab-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/ktechlab-devel</a><br>
<br></blockquote></div><br>