[Kde-bindings] Fwd: Re: Some questions about DCOP

[Richard Dale]

Ilyak Kasnacheev had some questions about DCOP, but my mail to him keeps 
bouncing. So I'll send it to kde-bindings and hope he subscribes.

-- Richard

----------    ----------

Subject: Re: Some questions about DCOP
Date: Wednesday 20 October 2004 13:29
From: Richard Dale <Richard_Dale at tipitina.demon.co.uk>
To: Ilyak Kasnacheev <ilyak at office.uw.ru>

Hi Ilyak

On Tuesday 19 October 2004 23:39, Ilyak Kasnacheev wrote:
> Hello there! I need to ask some questions about DCOP to understand it
> better.
>
> 1) What are DCOP signals? I beleive i will have to "Read the source,
> Luke!", but i doubt if i will understand them instantly.
> Would be better if you provide example where i can see one of them, and let
> strace and eyes do the rest :)

In C++ you define a signal in a header like this:

class KBookmarkNotifier : virtual public DCOPObject
{
  K_DCOP

public:
  KBookmarkNotifier(QCString objId = "KBookmarkNotifier") : DCOPObject(objId)
{}

k_dcop_signals:
  void addedBookmark( QString filename, QString url, QString text, QString
address, QString icon );
  void createdNewFolder( QString filename, QString text, QString address );
  void updatedAccessMetadata( QString filename, QString url );
};

That goes through a pre-processor, and generates code like this:

void KBookmarkNotifier::addedBookmark( QString arg0, QString arg1, QString
arg2, QString arg3, QString arg4 )
{
    QByteArray data;
    QDataStream arg( data, IO_WriteOnly );
    arg << arg0;
    arg << arg1;
    arg << arg2;
    arg << arg3;
    arg << arg4;
    emitDCOPSignal( "addedBookmark(QString,QString,QString,QString,QString)",
data );
}

So you already have the QByteArray/QDataStream marshalling to and from C#
types to implement calls on DCOPRefs, and it should be more of the same.

In C# you could perhaps have Emit declared like this:

Emit(string name, params Object[])

Emit("addedBookmark", "foo", "bar");

And work out at runtime that the type signature was
'addedBookmark(QString,QString)' or whatever. Then call emitDCOPSignal() with
that, and a QDataStream with the two QStrings marshalled from the original
two C# strings.

So they're not too bad, DCOP slots are more work to implement..

> 2) if i do:
>  ICE.IceRegisterForProtocolSetup
>                                         ("DUMMY", "DUMMY", "DUMMY",
>                                          (Xlib.Xint)1, ref version,
>                                          (Xlib.Xint)1, authNames, ref
> authProc, null);
>
>                                  majorOpcode =
> (int)ICE.IceRegisterForProtocolSetup
>                                         (protocolName, vendor, release,
>                                          (Xlib.Xint)1, ref version,
>                                          (Xlib.Xint)1, authNames, ref
> authProc, null);
> it segvs :( So i have to hack this by setting majorOpcode = 2 and not doing
> first call. Any ideas?

I'm not sure you should need to do anything and the ICE level. Can't you just
use DCOPClient::call()?

> 3) As you noitced, i do not provide DcopResult, i return real Object as
> call result or throw Exception. Will i need to implement that hairy
> DCOPResult? (I think, for deferred calls - yes?)

No I think it looks fine as it is. I agree DCOPResult is pretty ugly..

> 4) I will consider renaming Dcop to DCOP everywhere :)

Sounds good..

> 5) What endiannes and byte size problems should i expect?

As long as you convert a C# int to a C++ and then use the '<<' operator onto
 a QDataStream, you shouldn't have a problem. I assume you do that already.

Regards
-- Richard

-------------------------------------------------------