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
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
