glib in kdesupport: yes or no?
mo002j at mail.rochester.edu
Mon Mar 10 06:29:46 GMT 2003
> Keep in mind a couple of things, 1) D-BUS is maybe 30% done if that
> and still open to large changes 2) there were more KDE developers
> initially involved than GNOME developers, quite a few people (a
> dozen-ish I think?).
Note that no group of KDE developers smaller than kde-core-devel is IMHO
adequate to make any sort of core decisions. Sure, it's the maintainers call,
but it affects other areas as well. I do, for instance, promise to fight for
every millisecond of startup time.
> I'd encourage everyone to get involved and to look at the
> design/implementation. The list archives contain all discussion that's
> occurred and have always been public. Also please feel welcome on
This is rather academic, since it has never been publically announced. That's
like saying something written in the bark of a tree 5 miles inside a forest
is public, in a way -- it's only public if you're already know about it,
anyway. Or, to be more concrete, it's like saying that you should know that
your planet is about to be destroyed since the plans were available, afte
rall, just a few light-years away.
> An important question for KDE is, *if* you were going to use it in
> addition to or instead of or as a backend for DCOP, how would that
> migration work, and how would the code be set up. e.g. would you a)
My question is how any of these would affect our stated commitment to keep a
stable API through ages.
You're, of course, also fully ignoring the issue of wire compatibility, which,
AFAIK, KDE has kept since 2.0.
I also have a simple question to ask to any person who wants to propose
breaking any API in a hypothetical KDE4: "Are you willing to port all the 3rd
The easiest path, of course, is to just use DCOP. And please don't tell me "it
requires Qt". If you can't re-implement QDataStream's marshalling, I dare say
you shouldn't be coding.
More information about the kde-core-devel