RFC: DBUS & KDE 4
thiago.macieira at kdemail.net
Wed Sep 29 16:39:31 BST 2004
Waldo Bastian wrote:
>2) Provide DBUS support, deprecate DCOP, convert at runtime all DCOP IPC
> to DBUS to provide 100% backwards compatibility.
>4) Replace DCOP with DBUS, adjust dcopidl to generate DBUS code instead of
>2) This sounds like the perfect solution, but is it feasible? It seems to
> me that conversion of the call arguments may be impossible in cases where
> the argument types are application defined. Due to the way DCOP works, it
> is only possible by the receiving and sending applications in such case
> to separate the different arguments. As such, such calls will always look
> different from a native DBUS call with the same arguments. Is that a
> problem? In which situations would that cause compatibility issues? Can
> those be solved in another way?
>4) This is the 95%  solution. I think it's easy to pull off and 95% of
> all code would never notice the difference. The 5% will mostly be KDE 3
> applications that run in a KDE 4 environment. But as I explained above,
> that 5% is still too much. Is there something that we can do to solve the
> issue for this 5%?
I agree with you that the combined solution of 2 and 4 seem to be the best
If I understand how that would work, we'd:
- convert dcopidl to dbusidl and have it generate D-BUS code. All KDE 4
applications would therefore talk D-BUS natively.
- write a DCOP-to-DBUS bridge (dcopserver being a D-BUS client, maybe?)
which would relay messages from DCOP to the D-BUS environment.
- make it so that our current DCOP interfaces when converted to D-BUS also
register a DCOP object name. Following Zack's suggestion, the registering
of "org.kde.kdesktop.KScreensaverIface" in D-BUS would also cause the DCOP
alias "kdesktop KScreensaverIface" to be generated.[1,2]
 Maybe we could even have a DCOP namespace inside D-BUS, such as
org.kde.dcop.kdesktop.KScreensaverIface, in order to allow easier mapping
between the interface names.
 As for the argument marshalling problem you raised, we'd be restricted
only to those application-defined arguments. We have already changed most
of our interface to not use such types, preferring instead basic,
predefined ones (QString, QStringList, etc.)
I believe that with  we'd also allow DBUS-to-DCOP relaying, since the
whole of DCOP would be contained within D-BUS, provided  is respected.
In the world of invented statistics, I think we could raise your 95% to
something around 99%. We'd be left with only those functions that take
non-standard parameters. Those functions already can't be called from kdcop
or from the dcop command-line program, since they don't know how to
marshall objects like FocusPolicy, BackgroundOrigin or BackgroundMode (to
name a few that already are in our mainWindow DCOP object).
$ dcop kopete mainWindow setFocusPolicy 1
cannot handle datatype 'FocusPolicy'
As for the argument marshalling format of DCOP itself, I find it to be
flawed in that it doesn't specify the size of the argument that follows. It
depends exclusively on the other side knowing exactly what the argument
types are. Therefore, it is not extensible. Therefore, it has been long
coming that application-defined argument types would someday break.
Having said that, I don't believe doing that breaking now would have such a
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