Compatibility between KDE 3 and KDE 4
thiago at kde.org
Tue Jun 7 01:05:33 BST 2005
Martijn Klingens wrote:
>Exective summary: with this mail I would like to start collecting
> potential problems when having a mixed KDE 3/4 environment.
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
>* 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 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.
>* 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
Size: 189 bytes
Desc: not available
More information about the kde-core-devel