[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Compatibility between KDE 3 and KDE 4
From:       "Maksim Orlovich" <mo85 () cornell ! edu>
Date:       2005-06-07 1:20:23
Message-ID: 60963.209.210.140.188.1118107223.squirrel () 209 ! 210 ! 140 ! 188
[Download RAW message or body]

> Martijn Klingens wrote:
>>Exective summary: with this mail I would like to start collecting
>> potential problems when having a mixed KDE 3/4 environment.
>
> Hi Martijn,
>
> thanks for starting the thread
>
>>* KDE 3 apps using DCOP expect a DCOP server using a given binary
>> protocol. The KDE 3 DCOP server is found using
>> ~/.DCOPserver_$hostname_$display, and uses the ICE protocol for
>> authentication. KDE 4 will need a DCOP server that has the same
>> semantics, or a compatibility replacement. Are there problems to be
>> expected here, or will this stay in a way that's KDE 3 compatible?
>
> 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.

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.

> 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.

>>* kdeinit and notably kded need precautions to work with older binaries.
>>(Which? What are the usage patterns?)
>
> So the only possible outcome for this is to have both KDE3 kded and
> kdeinit and KDE4 kded and kdeinit --- loaded on demand, of course.

klauncher also fits in this to some extent.  An another option, though, is
to not load the KDE3 kded modules at all, and have the apps use I/O
slaves, etc., from the 4.0 desktop. Assuming wire compatibility is kept.
Not sure how to fit kdeinit quite in there, since I promptly forgot the
details of the kdeinit/klauncher dance.



[prev in list] [next in list] [prev in thread] [next in thread]