--nextPart44742787.A86ZnjuGbZ
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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=20
already solved that in the KDE4 port by explicitly setting the stream=20
version. QDataStream and all the classes support backwards-compatible=20
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=20
replacement for DCOP. Currently, D-BUS is the front-runner, especially=20
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=20
services into the DCOP namespace, allowing KDE3 and 4 apps to=20
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=20
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=20
just get a new soname. So, libkdecore will be version 5.0.0 when KDE4 is=20
released, meaning it will install a file called libkdecore.so.5.0.0, with=20
a soname of libkdecore.so.5.

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

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

As for the non-library shared objects (modules, plugins, kded/kdeinit=20
loadables), they are versioned as well. They live in $(libdir)/kde3 now,=20
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=20
built for KDE3. For kdeinit, the solution is easy: don't load the=20
libraries that will be upgraded. Of course, that also reads as "don't=20
preload libraries at all", which would mean kdeinit is useless. So we=20
don't want that.

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

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

So the only possible outcome for this is to have both KDE3 kded and=20
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=20
the how until we agree this is the solution, though.

=2D-=20
  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=E6s n=E1ht, se scieppend =FEone circolwyr=
de=20
wundorcr=E6ftl=EDge cennede and seo eor=F0e w=E6s idel and hit w=E6s g=F3d.

--nextPart44742787.A86ZnjuGbZ
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQBCpOTOM/XwBW70U1gRAhpdAJ9k8W6Ok9XmrZETRGxCJLIGdoZ9ywCdEWJW
mUzm0zMRHtiCm6F0JGDqugI=
=tFe3
-----END PGP SIGNATURE-----

--nextPart44742787.A86ZnjuGbZ--