[Kde-bindings] Implementing Ruby DCOP

Richard Dale Richard_Dale at tipitina.demon.co.uk
Fri Sep 26 10:33:13 UTC 2003


On Friday 26 September 2003 09:10, Alexander Kellett wrote:
> On Fri, Sep 26, 2003 at 07:57:11AM +0100, Richard Dale wrote:
> > I've decided the code for invoking a DCOP slot should look much like the
> > existing InvokeSlot class with a method copyArguments(). Instead of
> > copying the args from the QUObject's, it would copy them from the
> > QDataStream onto the Smoke::Stack, via the '>>' methods called from the
> > Smoke runtime. After that they would be much the same I think, apart from
> > another class DCOPReturnValue for taking the return value on the stack
> > and converting to the return value data stream.
>
> i'm a bit confused i must say
> this can all be done either by
> pure ruby (with qt and dcop methods)
> or, with pure c++ with no kde/qt
> involvement. ian geiser expressed
> interest in the second possibility
> as this provides a lightweight
> version with out the need to use
> a 10mb kde lib. but the pure ruby
> version really should be trivial
> now that you've cracked the big
> nut - ruby kde bindings.
I agree it's a good idea to do a second lightweight thing. But, I'm not so 
sure it's trivial to implement entirely in ruby - I think you need a proxy 
DCOPObject written in C++ for the dcop slots side. DCOPObject won't be in the 
Smoke runtime because it has pure virtual methods.

It might be easier to write the signals emitting code in ruby, you still need 
to get from a string with the C++ type signature for each arg from the signal 
string by looking up the '>>' methods and matching. I think that bit should 
be done in ruby anyway as it's a similar function to what do_method_missing() 
does in ruby.

I was just thinking of implementing it in the same style as the existing 
slots/signals stuff, as it's doing something pretty similar.

-- Richard


More information about the Kde-bindings mailing list