inter-plugin dependencies and BC

Mathieu Chouinard mchoui at e-c.qc.ca
Thu Sep 8 14:48:03 UTC 2005


On September 8, 2005 08:38, Roberto Raggi wrote:
> Hi!
> 
> On Thursday 08 September 2005 12:53, Alexander Dymo wrote:
> > Hi!
> > This mail summarises what we've discussed with Ian Geiser at aKademy.
> > Current policy in KDevelop is to put all public interfaces people may use
> > to lib/interfaces (libkdevelop.so) and implement them somewhere in shell.
> > This obviously means that we have lots of interfaces in the core but not
> > all of them are necessary for platform applications.
> this is impossible :-) we will create a *huge* set of interfaces. Things about 
> the C++ programming language support. I'd love to be able to write a plugin 
> that extends the C++ support. Of course such plugin needs to know a lot about 
> the classes *exposed* by the C++ support(e.g. the C++ AST, the way the C++ 
> support store the informations in the Code model, the way the C++ support 
> creates new classes, methods, ...).. We can generalize many things in 
> libkdevelop.so but not everything.
> 
> > The solution is to allow individual plugins to define their interfaces and
> > link other plugins to those interfaces. Basically, we'd like to introduce
> > inter-plugin dependencies (like Eclipse ;)). The only problem is that we'd
> I like it.
> 
> > be forced then to keep BC not only in the core interfaces, but in plugins
> > as well. And this is not good for us.
> we need some sort of versioning.
> 
> >
> > But there's a way to introduce inter-plugin dependencies and at the same
> > time do not care about BC. The solutions is simple - we can use
> > QMetaObject::invoke and some kind of IDL compiler.
> > Please take a look at attachment where a simple model of kdevelop
> > architecture is implemented and two plugins (plugin1 and plugin2) are
> > created.
> I'm not 100% sure it is a good idea to create/use such tool.
> 
> > What do you think about exposing interfaces in that way?
> > PS: If we do that, we could move more interfaces from the core to plugins
> > (like in Eclipse where you have runtime plugin, resources plugin, etc.).
> I'm all for it. I think we already discussed something like that one or two 
> years ago. In Qt Designer 4 I *solved* the problem with a library called 
> "extension framework". The extension framework is an implementation of the 
> adaptor pattern (eclipse uses the same patter to extend the resources.. 
> IAdatable, IAdapter, IAdapterFactory, IAdapterManager and so on).
> 
> With the extension framework is possible to extend an existing object at 
> runtime. This is very useful for extening an object without breaking the BC, 
> of for introducing a new version of the interface. For instance suppose you 
> have two version of an interface
> 
> struct MyInterfaceV1
> { ...
>   virtual void method1()  = 0;
> };
> Q_DECLARE_EXTENSION_INTERFACE(MyInterfaceV1, "org.kdevelop.iface.v1")
> 
> struct MyInterfaceV2
> { ...
>  virtual void method1() = 0;
>  virtual void method2() = 0;
> };
> Q_DECLARE_EXTENSION_INTERFACE(MyInterfaceV2, "org.kdevelop.iface.v2")
> 
> now you can ask which extension your instance support. Of course the instance 
> can support both extension. 
> 
>  if (MyInterfaceV1 *v1 = qt_extension<MyInterfaceV1*>(m, instance))
>    {
>       // do something
>    }
>  else if (MyInterfaceV2 *v2 = qt_extension<MyInterfaceV2*>(m, instance))
>    {
>       // do something else
>    }
> 
> the qt_extension<> uses strings as typeid. So if you change the declaration
> Q_DECLARE_EXTENSION_INTERFACE(MyInterfaceV2, "org.kdevelop.iface.v2")
> with
> Q_DECLARE_EXTENSION_INTERFACE(MyInterfaceV2, "org.kdevelop.iface.v2-abi2")
> 
> the qt_extension<MyInterfaceV2*>(..) will fail and return a 0x0 pointer.. so 
> there is no crash and we can show a message saying the plugin doesn't support 
> the extension *whatever*.
> 
> an instance can implement more then one type of extension.. And the cool thing 
> about the extension framework is that different instances comunicate using 
> "abstract classes" (handles). So they don't have to link with a library. If 
> you're interesting I can write a small example that show how to use the 
> extension framework from two different plugins. 
> 
> ciao robe
I'm definitly interested in this example :)
Mathieu
---
What this world needs is a good five-dollar plasma weapon.




More information about the KDevelop-devel mailing list