Compatibility between KDE 3 and KDE 4

Martijn Klingens klingens at
Tue Jun 7 09:04:09 BST 2005

Maksim Orlovich said:
>> There's the problem of Qt's datastream changing internally, but we have
>> already solved that in the KDE4 port by explicitly setting the stream
>> version. QDataStream and all the classes support backwards-compatible
>> marshalling since Qt 1.x, so it is quite easy.
> Yep,and I've tested this to some extent early in the port (e.g. talking to
> KDE3 apps using a KDE4 dcop command), but not extensively. A problem is
> that tons of code marshalls manually, so there need to be zillions of
> setVersion calls (or better, the code needs to be converted to use
> DCOPRef). Some of the marshalling is quite sloppy, too, though.

Apart from the fact that this subthread starts to lean towards trying to
find solutions rather than information gathering, porting KDE 4 code to
DCOPref might help a lot, if DCOP is to survive in the first place. (Read
on below for more.)

> KBuildSycoca situation is similar: with setVersion calls in place, last I
> checked it could open my 3.x ksycoca file. And of course ksycoca itself is
> designed to be expandable in a backwards compatible way, with version
> numbers and everything.

We could however also consider to write two sycoca's from kbuildsycoca.
That way the sycoca is optimized for either platform, but centrally
managed, so only one application needs setVersion().

>> But to add to the discussion, we have in our KDE4 goals to evaluate a
>> replacement for DCOP. Currently, D-BUS is the front-runner, especially
>> because system messages are being sent using it (cf. HAL).
> And cooperation with the KDE3 apps would be one advantage of not
> switching.

In fact, I think it's a reason to switch ;-)

Explanation: we provide KDE 3-compatible DCOP interfaces, but can rework
our 'real' interfaces. Many many apps need cleanups in the DCOP ifaces,
apps might change name (kdesktop/kicker->plasma to name one), and
moreover, if only from a performance pov we probably want to use Qt 4
native datastream format whenever possible. It also allows us to extend
the DCOP4/dbus/... format for our future needs without worrying about KDE

Anyway, the problem is the stream format, the solution part is for later.


More information about the kde-core-devel mailing list