Compatibility between KDE 3 and KDE 4
klingens at kde.org
Mon Jun 6 22:39:11 BST 2005
Exective summary: with this mail I would like to start collecting potential
problems when having a mixed KDE 3/4 environment.
Until now we haven't really bothered about compatibility between major KDE
releases. KDE 1 apps didn't run well in a KDE 2 environment, even if the old
libs were still available, and the same happened between KDE 2 and KDE 3.
Without having the old libs around it was not possible *at all* to run old
apps due to us breaking binary compatibility.
Back then we were small and the Unix desktop was small. With KDE gaining lots
of momentum it's time to look forward to KDE 4 and protect investments made
by 3rd party developers and ISVs to our current platform. After all we want
them to leverage our great API and not scare them away because we're about to
break BC with a new release. We also don't want them waiting with developing
new KDE applications until KDE 4 is ready, because KDE 3 is still the
platform of choice for quite a while. And rightfully so, despite all new cool
stuff in Qt 4 and soon KDE 4 even our current API is still lightyears ahead
of the competition, so there's no reason for ISVs to wait for KDE 4.
So, in order to make the KDE 3 platform sustainable until well after the KDE 4
release we first need to identify the potential problems. I don't want to
focus on the answers yet, first I'd like to see all pitfalls together to keep
the discussion focussed.
Please add to the list below anything that is missing. Also please correct
anything that's wrong, I'm working off the top of my head now. A first
* 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?
* KDE 3 apps expect a ksycoca using a specific binary layout. ksycoca is
designed to be upwards compatible within KDE versions, but not necessarily to
survive major upgrades to e.g. internal representations of variables. Are
there problems to be expected here wrt Qt 3/4 ?
* $KDEHOME and $KDEDIRS have a defined meanign that will have to be preserved
* $KDEDIR is scheduled for removal since KDE 2, and KDE 2 and KDE 3 both also
support $KDEDIRS, so this is a special case that we can remove now after 5
years of extended support.
* 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.
* KDE libraries have to coexist alongside. That can be handled by just setting
$PREFIX accordingly though, AFAICS
* kdeinit and notably kded need precautions to work with older binaries.
(Which? What are the usage patterns?)
* DCOP interfaces will need to remain compatible or provide compatibility
wrappers, at least for the major applications.
* kdialog will need to stay syntax compatible.
All in all quite a long list. Whether we can do anything about it is for
later, for now I just want the list to be complete. After that we can debate
whether we can put any effort in compat, and if not, at least how to avoid
the problem when going to KDE 5.
More information about the kde-core-devel