[Kde-bindings] KDE/kdebindings

[Richard Dale]

On Monday 09 June 2008 18:13:43 Arno Rehn wrote:
> Am Montag 09 Juni 2008 15:28:21 schrieb Richard Dale:
> > On Monday 09 June 2008 13:28:13 Arno Rehn wrote:
> > > > The only thing I don't like is subclassing SmokeInvocation and giving
> > > > it a different name in the generated code. That seems pointless and
> > > > ugly to me any old static constructor will load the smoke lib. In the
> > > > soprano bindings I had a source called 'Soprano.cs' with this:
> > > >
> > > > namespace Soprano {
> > > >       using Qyoto;
> > > >       using System;
> > > >       using System.Runtime.InteropServices;
> > > >
> > > >       public class InitSoprano {
> > > >               [DllImport("libsoprano-sharp", CharSet=CharSet.Ansi)]
> > > >               static extern void Init_soprano();
> > > >
> > > >               static InitSoprano() {
> > > >                       Init_soprano();
> > > >               }
> > > >       }
> > > > }
> > > >
> > > > And just left SmokeInvocation as it was in the generated code. So I
> > > > think we should have a Kimono.cs source with the same thing in it.
> > >
> > > My intention was to simplify the code for those who actually use the C#
> > > bindings. And a static constructor is called when the class that
> > > defines it is used for the first time. Since SmokeInvocation is always
> > > used before any other thing, it makes sure that the smoke lib is always
> > > loaded. If we put that code into another class that is completely
> > > unrelated to the binding, we will always have to call InitFoo() if we
> > > want to use it. So subclassing SmokeInvocation for the different
> > > bindings seemed to be the best solution to me.
> >
> > OK, I understand the problem now, but I still think the solution of
> > renaming SmokeInvocation is ugly. I found this after a bit of googling:
> >
> > "Note, however, that you *can* put code in your AppDomain to execute when
> > *another* DLL loads. (The AppDomain.AssemblyLoad event.) That means you
> > can write your code once, and so long as that event handler is added
> > before the other assemblies are loaded, you can do all the appropriate
> > things."
> >
> > http://osdir.com/ml/windows.devel.dotnet.cx/2004-01/msg00064.html
> >
> > So is the Qyoto dll in an AppDomain, or can we put it in one?
>
> Yes, of couse the Qyoto dll is always in an AppDomain. So we'd have to
> define a standard class class name, whoch holds a method to do the
> initialization. Whenever an assembly is loaded, we have to look for that
> class via reflection and call the initialization method.
I've read a bit more about this, and it seems quite straightforward to 
implement - you just set up a static delegate that receives the dll loaded 
event and then do what you say. So I would prefer doing it this way - an app 
domain called 'Qyoto' and an initialize class called InitSmoke in each dll 
for instance.

> > > > When I tried to compile the Kimono code I got an error about an
> > > > unimplemented abstract method. I wonder if the easiest thing to fix
> > > > that is to have partial classes with the missing methods in them with
> > > > empty bodies.
> > >
> > > Mh, I thought I had marked all the classes 'abstract' by hand that gave
> > > errors. Maybe we need to look if all abstract members are implemented
> > > in a subclass of an abstract class and if not, mark it abstract as
> > > well.
> >
> > The problem is that in C++ you can actually instantiate a class that has
> > only some of the pure virtual methods of a super class implemented. So
> > instead of abstract methods we need to add empty actual methods to avoid
> > needing to make the class abstract. Maybe we can do it automatically. I
> > had the same problem with the Soprano StorageModel class which is missing
> > a load of methods that are pure virtual in the super class.
>
> Maybe we should drop the abstract keyword completely and just generate
> normal virtual methods with the appropiate smoke calls. This would make
> things much easier, since we wouldn't need some special subclasses with the
> abstract methods implemented via additional P/Invokes if a method returns
> such an abstract class (as it's the case with QAbstractItemModel and
> several other QAbstract* classes).
I think Qt does a lot of that abstract stuff, but KDE much less so. As you've 
already implemented the Qt side, I think we should try and leave it as it is.

I would rather keep the abstract methods, and try to get it to work. We need 
to find if the current class doesn't have any pure virtuals (we already test 
for that), and if it doesn't and yet doesn't implement some inherited 
abstract methods we add empty methods for each missing one.

-- Richard