[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    RE: A new framework for embedding ... without CORBA
From:       David Faure <David.Faure () CRAMER ! CO ! UK>
Date:       1999-09-29 10:41:41
[Download RAW message or body]

Well... it seems we have quite a difficult decision to take here, and
I'm very undecided about which camp to choose.

We are faced to the usual problem of choosing between an open solution
and a proprietary solution.
The open one looks good on the paper and allows "third-parties
implementation"
such as a gtk-based openparts, or anything other non-KDE implementation.
The proprietary solution is much more efficient since it allows to use
directly native stuff (like passing around QImages and other stuff) 
but ties the implementations to Qt.

The current openparts requires a duplication of the kdeui/qt API,
which is a pain (my recent point was that I was looking for the KAccelMenu 
equivalent in openparts, and it's simply not there, and concluded that
duplicating everything is awful) - but as Waldo says it's the ONLY way
to allow implementations in other toolkits. I withdraw this wrong point of
mine.
If we keep the current openparts, I'll simply implement the equivalent
of KAccelMenu in it - and I'm sure anybody could implement it for another
toolkit when necessary. We don't what the future is, so of course we don't
know if the open solution will really be helpful - but since we already have
it,
why go for a closed solution now...

Another flaw of the current stuff is unstability of embedding. But here
we have to determine whether it's a design problem or an implementation
problem.
If it's a design problem, then Reggie's right and we can't keep something
like that. If it's an implementation problem, let's fix it.
As far as I know openparts (but I might be wrong), there's no design problem
in 
the way embedding is currently done. It could work, and it even half works
currently. So my point is : let's fix it.

There's no point in throwing away a good design (open solution) because its
current implementation isn't robust enough.
And if we need to improve the interface for making it more robust (I'm
referring
to some well-known PS file recently sent around), then let's do it.
I'm sure the corba experts out there can provide us with ways of improving
robustness - like checking if the server is still running before invoking
it, ...

I'm still undecided, but Waldo's point has made me a bit colder about
canossa.
And of course, the fact that we know now that we have ways of improving the
current stuff, cuteidl being one of the ways, and hopefully others coming
soon.

PS : is Torben subscribed to kde-core-devel ?

--
David Faure
faure@kde.org - KDE developer
david@mandrakesoft.com - Mandrake
david.faure@cramer.co.uk - Cramer Systems

[prev in list] [next in list] [prev in thread] [next in thread]