|
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:
|
- Provide DBUS support in addition to current DCOP support, keep the two worlds separate.
- Provide DBUS support, deprecate DCOP, convert at runtime all DCOP IPC to DBUS to provide 100% backwards compatibility.
- Replace DCOP with DBUS, provide no compatibility.
- Replace DCOP with DBUS, adjust dcopidl to generate DBUS code instead of DCOP.
- Something better :-)
|
|
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
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
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.
|
