From kde-core-devel  Thu Sep 30 09:48:55 2004
From: Thiago Macieira <thiago.macieira () kdemail ! net>
Date: Thu, 30 Sep 2004 09:48:55 +0000
To: kde-core-devel
Subject: Re: RFC: DBUS & KDE 4
Message-Id: <200409300648.56142.thiago.macieira () kdemail ! net>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=109653776206878
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart365645286.3AlchEOKy2"

--nextPart365645286.3AlchEOKy2
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Lubos Lunak wrote:
>> Coming from DCOP, we may not be able to remarshall for DBUS properly if
>> custom types are involved.
>
> Why not? The custom DCOP type would be remarshalled as the CUSTOM type
> from DBUS. The KDE4 app would then read it using QDataStream. That'd be
> indeed some work, but I don't think that would be different from doing it
> for everything like you want. Moreover I'd expect KDE3->KDE4 calls with
> custom data types to be rather rare.

It means that whatever is doing the translating from DCOP to DBUS has to=20
know all the types involved in the transmission.

Take, for instance, the FocusPolicy enum that is a parameter to=20
mainWindow:setFocusPolicy. The translator has to know it's transmitted as=20
'int'.

We can't simply place it into the DBUS 'custom' type because DCOP does not=
=20
transmit the object length. It depends on the destination knowing what to=20
do with the stream.

=2D-=20
  Thiago Macieira  -  Registered Linux user #65028
   thiago (AT) macieira (DOT) info
    ICQ UIN: 1967141   PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--nextPart365645286.3AlchEOKy2
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQBBW9aIM/XwBW70U1gRAlT3AKCedleit2IsM1el13n+bjHVv5NKrACgsWQb
+ew18yXRxGwTOs+LC4I5Wcs=
=Q3oW
-----END PGP SIGNATURE-----

--nextPart365645286.3AlchEOKy2--