Regarding the debate about CORBA et al, here's my take on the situation
as someone who has experienced what it's like to work with.

It has taken me about 4 months to get to grips with CORBA. It was only
last week when I truly began to understand what was going on and how
things should work. I'm a fast learner, but being poor, couldn't afford
a book.

Expecting KDE developers to suddenly jump in and start using CORBA in
their apps, and making OpenParts, is perhaps a little optimistic.

The various docs about KOM/OP/kded etc are good, but that still leaves
the learning curve for CORBA in general. Another thing that doesn't help
is the examples not compiling or running (every time I've tried to get
them going I've failed, and I can get any 'normal' KDE/Qt code working,
no matter what it is !)

So to expect that GNOME developers, many of whom do not understand OO
enough to write in C++, to learn CORBA and then learn how to use KOM/OP,
while the implementation (of KOM/OP) is fairly shaky, is even more
optimistic.

That's the reason I think that GNOME (and KDE) developers haven't jumped
in. This is of course no-one's 'fault' - it's simply too much at once.

My point is that the reason for the lack of uptake is not only due to
people not wanting to use the technology, more a lack of skills.

With cuteidl, I have suddenly made the leap from struggling-to-do-anything
to kab2-works !

If KOM/OP had hand-holding tutorials, together with some real-world
examples (I don't mean 'read the source of KOffice' - until recently I
didn't understand a word of it) then uptake would be much faster.

Another thing that would trigger an upsurgence of interest (and hence
an increased number of developers working on the core technologies) would
be to actually take a GNOME app and embed it into a KDE app.

If the GNOME folks could actually see something working, then they'd
be more inclined to look at KOM/OP.

As to what should happen now, I don't really mind. I've done the backend
stuff of kab2. The next thing that has to be done with kab2 is to get the
UI working. That'll have to wait until a decision is made about KOM/OP.

Of course, the kab2 backend is currently not working due to some strange
problem with kded. I mailed kde-devel and no-one answered. No-one's
going to use this stuff unless it works !

If I were to give my honest opinion, I'd have to say I agree with Kurt.
I think it's more important for us to have working code than interoperability.
So far I haven't seen any practical examples of GNOME/KDE integration. To
be honest, I haven't actually seen GNOME do very much at all. We can't
sit on our hands until they catch up.

I was contacted by the KOrganiser maintainer with a question: 'What do I
have to do to make KOrganiser do the necessaries for pim/kde2'. I replied
saying that he should create an idl, adjust KOrganiser so that it can
be run as a server, providing interfaces for things like searching, and
turn his UI elements into OpenParts. He didn't write back !

So I say either make KOM/OP work now, and help non-KOffice developers
use them, or drop them quickly to give us time to learn how to use
canossa.

Cheers,
Rik