[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Compatibility between KDE 3 and KDE 4
From:       Martijn Klingens <klingens () kde ! org>
Date:       2005-06-06 21:39:11
Message-ID: 200506062339.11468.klingens () kde ! org
[Download RAW message or body]

Hiya,

Exective summary: with this mail I would like to start collecting potential 
problems when having a mixed KDE 3/4 environment.

Long version:
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 
incomplete start:

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

-- 
Martijn
[prev in list] [next in list] [prev in thread] [next in thread]