[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:       Simon Hausmann <shaus () uermel ! Med ! Uni-Magdeburg ! DE>
Date:       1999-09-29 11:56:27
[Download RAW message or body]


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
> 
> 

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