From kde-core-devel Wed Sep 29 10:41:41 1999 From: David Faure Date: Wed, 29 Sep 1999 10:41:41 +0000 To: kde-core-devel Subject: RE: A new framework for embedding ... without CORBA X-MARC-Message: https://marc.info/?l=kde-core-devel&m=93860178618368 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