8th October 2004

This Week...

KSpread improves gnumeric export filter. Krita adds a crop tool. Kexi adds database command line options. gmail.google.com now works in Konqueror. Kicker clock supports NTP. Whither DBUS and Kde?

Kde 3.3.1 was tagged last sunday, and is being prepared for release.

An interesting discussion of D-BUS took place on kde-core-devel. The thread starts here.

Waldo Bastian proposed 5 solutions:

And the discussion ensued from there. Some highlights in no particular order...

DBUS is great for things like "new disk in drive" or "camera plugged in", but the largest usecase we have in dcop right now is "is this app running?" and other communication between applications on a single session. I still have not seen answered if dbus can fit both of those scenarios effectively. Waldo, Harry, Havoc please point me to some numbers if I am horribly off here.

http://lists.kde.org/?l=kde-core-devel&m=109647249214611&w=2

It seems to me that conversion of the call arguments may be impossible in cases where the argument types are application defined. This is possible via QMetaType and the custom D-BUS type, I use this trick to transfer more complicated stuff in my accessibility bridge.

http://lists.kde.org/?l=kde-core-devel&m=109647624715773&w=2

nope, there's no glib dependency. The API is a bit glib-ish, but we don't care since we do not expose it in our wrapper.

http://lists.kde.org/?l=kde-core-devel&m=109647353013165&w=2

KDE 4 applications would then be reachable with "DCOP over DBUS" and "DBUS" and exisiting code that makes (hand coded) DCOP calls in KDE would use "DCOP over DBUS" while dcopidl in KDE4 would generate "DBUS" calls. For KDE 3 compatibility we could extend the dcopserver to change DCOP calls to DBUS clients into "DCOP over DBUS" calls. The dcopserver would then be an optional server in order to obtain KDE3 compatibility.

http://lists.kde.org/?l=kde-core-devel&m=109647704712328&w=2

i have a draft for a new systray spec that resolves the insanity of the current one. as it stands it relies on DBUS, since it provides certain things (e.g. Message Busses) that DCOP doesn't which are needed for something like the systray. so... it's coming. it's just that DBUS is so relatively new that adoption is only beginning.

http://lists.kde.org/?l=kde-core-devel&m=109647746222090&w=2

DBUS better facilitates things like TCP access in the sense that the idea is to have two separate DBUS'es. One for inter-user communication (system) and one restricted to a single user only (the DCOP model). Everything you attach to the system DBUS creates security concerns, which is in one way a bad thing, some of these concerns will prove to be actual security problems. And a good thing, because all services attached to the system DBUS are supposed to be designed with security in mind, so when you grant TCP access to the system DBUS it should not imply instant shell access.

http://lists.kde.org/?l=kde-core-devel&m=109647859323328&w=2

See, that's partly why I am really uncomfortable about this stuff. It's 90% buzz, 10% technology. And buzz has rather circural nature: people get convinced that everyone will use X, so everyone ends up using X. D-BUS hardly excites me because I don't see anything particularly innovative in it (while DCOP's very existance was quite a radical idea, and the whole key/call causality tracing things is interesting). D-BUS seems mostly like DCOP rehashed by someone who didn't know DCOP and ICE very well, so ended up making some things worse w/some things better, while reproducing a lot of the really mundane stuff.

http://lists.kde.org/?l=kde-core-devel&m=109656030004288&w=2

the question has be posed, but not answered: can the "stuff that is worse" be fixed and how much effort would that take? i know earlier you spoke about deadlock issues, can you point to where these problems exist exactly[1]?

http://lists.kde.org/?l=kde-core-devel&m=109656225322586&w=2

That said, D-BUS offers all that I wanted when I started hacking on the command-line dcop client and much more, so I'm obviously strongly in favour of it.

http://lists.kde.org/?l=kde-core-devel&m=109667224532163&w=2

I'm reading the thread in order so hopefully won't repeat things already said, but here goes. Some discussion about the dbus type system and encoding:
http://freedesktop.org/pipermail/dbus/2004-June/001169.html

See also doc/TODO as always,
http://freedesktop.org/Software/dbus/doc/TODO
Havoc http://lists.kde.org/?l=kde-core-devel&m=109675879304488&w=2

Next week I will resume the aKademy presentations with coverage of the Gstreamer talk. The gstreamer vs. competition slide blew some circuits which require some rebuilding.

Statistics

Commits	3054 by 214 developers, 364668 lines modified, 963 new files
Open Bugs	7452
Open Wishes	6965
Bugs Opened	328 in the last 7 days
Bugs Closed	212 in the last 7 days

Commit Summary

Module	Commits
kde-i18n	1482
kdepim	222
kdelibs	141
kdeextragear-1	140
koffice	127
kdeextragear-2	114
kdenonbeta	103
kdeextragear-3	94
kdebase	89
kdebindings	84

Lines	Developer	Commits
31035	Thierry Vignaud	380
17390	Stephan Kulow	144
17256	David Faure	85
5783	Stefan Asserhäll	82
2728	Andrew Coles	81
5760	Federico Zenith	73
23534	Richard Dale	72
14737	Gilles Caulier	66
697	Nicolas Goutte	62
4186	Ludovic Grossard	61

Internationalization (i18n) Status

Language	Percentage Complete
British English (en_GB)	99.88%
Swedish (sv)	99.55%
Portuguese (pt)	97.11%
Danish (da)	94.21%
Spanish (es)	93.55%
Dutch (nl)	93.44%
Estonian (et)	92.39%
Italian (it)	91.71%
Tamil (ta)	90.62%
Serbian (sr)	90.25%

Bug Killers

Person	Bugs Closed
Reinhold Kainhofer	33
Stephan Kulow	16
Adriaan de Groot	16
Stephan Binner	15
Mark Kretschmann	12
Charles Samuels	12
Christoph Cullmann	11
Tom Albers	11
Harri Porten	8
Michael Pyne	7

No commits found

Thanks for reading the KDE Commit-Digest!