10th June 2005

This Week...

DCOP Client/Server implemented for KDE win32. New videodvd:/ kioslave does on the fly decryption from DVD. Kopete implements Yahoo! Stealth feature. Opening of WebCore development yields fruit: DOMParser, and CSS fixes.

Changing major versions of KDE present opportunities to make the major changes needed to improve the platform. But how will third party KDE 3 applications run? Martijn Klingens started a thread entitled "Compatibility between KDE 3 and KDE 4" [1]. Here are some of the issues:

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.

Thiago Macieira added another issue:[2]

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.

Maksim Orlovich who has been working on the porting effort described his experience with DCOP: [3]

Yep,and I've tested this to some extent early in the port (e.g. talking to KDE3 apps using a KDE4 dcop command), but not extensively. A problem is that tons of code marshalls manually, so there need to be zillions of setVersion calls (or better, the code needs to be converted to use DCOPRef). Some of the marshalling is quite sloppy, too, though.

KBuildSycoca situation is similar: with setVersion calls in place, last I checked it could open my 3.x ksycoca file. And of course ksycoca itself is designed to be expandable in a backwards compatible way, with version numbers and everything.

Thiago Macieira reminds us of the proposed direction regarding DCOP and D-BUS [4]

But from the ideas we got last time we discussed D-BUS here, I'd say that it is feasible to give full access to the new environment, not just a compatibility area. In other words, I think the conclusion was:

KDE4 apps will speak D-BUS natively
KDE3 apps can talk to KDE4 apps normally, and vice-versa
KDE3 apps cannot talk to non-KDE D-BUS apps
non-KDE D-BUS apps can send simple messages that are to be relayed into DCOP

This would, of course, require that we have a dcopserver. In fact, if we want to support DCOP at all, we'll need dcopserver.

Obviously many of these issues are unresolved, and solutions will come when someone starts writing code.

[1] http://lists.kde.org/?l=kde-core-devel&m=111809395900396&w=2
[2] http://lists.kde.org/?l=kde-core-devel&m=111810275129133&w=2
[3] http://lists.kde.org/?l=kde-core-devel&m=111810723200064&w=2
[4] http://lists.kde.org/?l=kde-core-devel&m=111814373103246&w=2

Statistics

Commits	2860 by 202 developers, 53426 lines modified, 2587 new files
Open Bugs	8988
Open Wishes	8402
Bugs Opened	321 in the last 7 days
Bugs Closed	325 in the last 7 days

Commit Summary

Module	Commits
l10n	429
stable	343
extragear	281
work	273
www	267
kdepim	173
kdeedu	135
koffice	131
kdenonbeta	111
digikam	97

Lines	Developer	Commits
2005	Laurent Montel	107
369	David Faure	75
2021	Nikolas Zimmermann	67
499	Pino Toscano	57
132	Pedro Morais	56
626	Dirk Mueller	56
219	Gilles Caulier	55
763	Albert Astals Cid	54
303	Rinse de Vries	52
869	George Staikos	43

Internationalization (i18n) Status

Language	Percentage Complete
British English (en_GB)	99.42%
Swedish (sv)	97.73%
Portuguese (pt)	95.9%
Danish (da)	95.15%
Estonian (et)	93.38%
Italian (it)	92.74%
French (fr)	92.27%
Serbian (sr)	91.29%
Dutch (nl)	91%
Spanish (es)	90.7%

Bug Killers

Person	Bugs Closed
Aaron J. Seigo	18
Thiago Macieira	18
Andreas Gungl	14
Daniel Molkentin	12
Andreas Beckermann	12
Luboš Luňák	12
Maks Orlovich	11
Till Adam	11
James Richard Tyrer	10
Albert Astals Cid	10

No commits found

Thanks for reading the KDE Commit-Digest!