RFC: DBUS & KDE 4
thiago.macieira at kdemail.net
Wed Sep 29 21:51:19 BST 2004
Waldo Bastian wrote:
>Let me combine a few of the suggestions in a somewhat complete solution:
>For compatibility we could generate demarshalling for both the DCOP and
> DBUS calling formats (and mark new interface so that we can only generate
> DBUS interfaces for those). Then we can have the same interfaces
> available in the DCOP and DBUS universe.
This solution would allow any calls coming from DCOP and from DBUS to work,
even those using custom datatypes.
I am assuming that our non-standard types used all over (QPoint,
QStringList, etc.) would be mapped to a DBUS CUSTOM type and still be
>To reduce the overhead of the generated code we could even identify cases
> (at compile time) where (the incoming) calls to the
>org.kde.dcop.kdesktop.KScreensaverIface.lock interface can be
> automatically converted to calls to its
> org.kde.kdesktop.KScreensaverIface.lock counterpart. (Must be careful
> with return types though)
Sorry, I didn't understand this one.
What do you mean?
>KDE 4 applications would then be reachable with "DCOP over DBUS" and
> "DBUS" and exisiting code that makes (hand coded) DCOP calls in KDE would
> use "DCOP over DBUS" while dcopidl in KDE4 would generate "DBUS" calls.
> For KDE 3 compatibility we could extend the dcopserver to change DCOP
> calls to DBUS clients into "DCOP over DBUS" calls. The dcopserver would
> then be an optional server in order to obtain KDE3 compatibility.
What is not being addressed here is the DBUS-to-DCOP calls.
For KDE4 apps, calling a "DCOP over DBUS" method would trigger DCOP
marshalling and route the call via DBUS to the dcopserver, which would then
relay to the destination. This will require hardcoding of the DCOP aliases
(org.kde.dcop) and making a special DBUS call.
Non-KDE4 apps will not be able to call any of the interfaces present under
org.kde.dcop.* unless they themselves use our (tentatively so-called)
"libkdbus" or "libdcop+dbus".
I would much rather keep the DBUS section clean and let the dcopserver do
the transmarshalling. Simple types and strings are easy; common custom
types like QStringList, QPoint, QCursor, QPixmap, QPalette, QSize would be
encoded to their DBUS equivalents -- which have to exist anyways for DCOP
to be replaced with DBUS.
The only problem would be custom datatypes (like enums), which should be
avoided at all costs as of now. In those cases, when transmarshalling
fails, dcopserver would transmit the whole QDataStream over D-BUS. At
compile-time, we would also detect those border cases and write DCOP
demarshalling code on the app.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel