From kde-core-devel Wed Sep 29 11:56:27 1999 From: Simon Hausmann Date: Wed, 29 Sep 1999 11:56:27 +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=93860598522159 Do we need a CORBA based standard for embedding, or is a plain C++/shlib based standard enough? IMHO we don't need CORBA here. There are two points about embedding I think. One is about describing and creating (and sharing) a GUI, and the other one is about embedding an X Window. For the second point we surely don't need CORBA, and for first point I think we don't need it either. We can describe a complete GUI in XML. The remaining problem is: How is the GUI connected to the component, so that when some action takes place (use clicks on a toolbar-button or so) a specific callback method in the component gets called, and how can the component change the GUI elements at run-time. These points, the way the component is "connected" to it's GUI elements, is a very toolkit specific issue IMHO. You can of course attempt to hide this behind a CORBA interface, like it is done in OpenPartsUI, but in the end it restricts the developer a lot (David's accel issue is a good example) . In the end we could attempt to develop a UI CORBA interface, which is "compatible" with both, Qt and GTK, but this would require (probably massive) changes in the current OpenPartsUI interfaces I think (I admit though that I'm not very skilled with GTK, but from what I saw in Bonobo, the way they create and connect to a GUI is somewhat different in several aspects) . I'm not sure, but I guess I'd be called a dreamer if I'd suggest to start a discussion about creating such a "unified" interface between Qt and GTK. And I guess it is very likely that the performance of a system built on such an interface is even worse that the current OpenPartsUI. That's one of the reasons why I support Torben's proposal, as we gain performance and flexibility (with Qt's *impressive* QAction concept) , without the trouble of defining everything in IDL and hoping for someone to implement it in GTK ;-) Ciao, Simon On Wed, 29 Sep 1999, David Faure wrote: > 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 > >