Compatibility between KDE 3 and KDE 4
klingens at kde.org
Tue Jun 7 08:54:59 BST 2005
Thiago Macieira said:
> 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
Do you want KDE 3 DCOP to be upwards compatible to KDE 4 IPC or just allow
KDE 3 apps to work in a KDE 4 environment? The subtle difference is that
in the latter case we only need to provide the existing interfaces without
caring about new ones that might appear.
Without talking about possible ways to reach either goals (as I said,
first collect the issues), I myself would opt for the latter.
>>* 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.
For clarity, the name of the containing folder or the actual filename? In
the latter case e.g. kdeglobals would become kde4globals in $KDEHOME as
well. (Hmm, might not be a bad idea...)
> 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.
That was my initial thought too.
> 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.
The "how" can be done by adding glue code in kdelibs 3.5 , or even release
a kdelibs 3.6 alongside KDE 4 that provides the glue. But those are just
some options, don't reply to this paragraph yet :)
More information about the kde-core-devel