Compatibility between KDE 3 and KDE 4

[Thiago Macieira]

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.

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

If we do make the switch to D-BUS, we'll also have to map the KDE4 
services into the DCOP namespace, allowing KDE3 and 4 apps to 
interoperate.

>* Kiosk profiles are governed through /etc/kde3rc under SuSE, but not
> for a vanilla KDE, where it is just /etc/kderc. The profiles themselves
> default to /etc/kde-profile and /etc/kde-user-profile. Potential
> problems arise in overlapping config files (kdeglobals for KDE 3 and
> 4), so KDE 4 will need a more future-proof naming scheme.

Just add the "4" to the name, if the layout of those files is not 
compatible with the KDE3 apps.

>* KDE libraries have to coexist alongside. That can be handled by just
> setting $PREFIX accordingly though, AFAICS

Actually, this is one of the easiest parts: the libraries themselves will 
just get a new soname. So, libkdecore will be version 5.0.0 when KDE4 is 
released, meaning it will install a file called libkdecore.so.5.0.0, with 
a soname of libkdecore.so.5.

That won't clash with libkdecore.so.4, which is what KDE3 uses. 

The libkdecore.so file is only used for development. Developers, on the 
other hand, if they want to build apps for both platforms, will need 
different prefixes. Not only libraries would clash, but include headers 
as well.

As for the non-library shared objects (modules, plugins, kded/kdeinit 
loadables), they are versioned as well. They live in $(libdir)/kde3 now, 
and they'll be in $(libdir)/kde4 in the future.

But:

>* kdeinit and notably kded need precautions to work with older binaries.
>(Which? What are the usage patterns?)

Neither kdeinit nor kded from KDE4 will be able to load plugins/modules 
built for KDE3. For kdeinit, the solution is easy: don't load the 
libraries that will be upgraded. Of course, that also reads as "don't 
preload libraries at all", which would mean kdeinit is useless. So we 
don't want that.

For kded, it is more complicated, since modules are loaded into the same 
executable process (as opposed to kdeinit, which forks a new instance 
every time). If we were to load a KDE3 kded module, it would bring in all 
the KDE3 libraries, which means we would have both libkdecore.so.4 and 
libkdecore.so.5 in the same process.

It wouldn't be a problem if all KDE4 symbols lived in a different 
namespace than KDE3 symbols, but that option has been discarded.

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.

The next question would be: how do we do that? I think we should postpone 
the how until we agree this is the solution, though.

-- 
  Thiago Macieira  -  thiago (AT) macieira (DOT) info
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

1. On frumscafte, hwonne time_t wæs náht, se scieppend þone circolwyrde 
wundorcræftlíge cennede and seo eorðe wæs idel and hit wæs gód.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050606/48a516a1/attachment.sig>