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

List:       kde-core-devel
Subject:    RE: More thoughts about embedding
From:       David Faure <David.Faure () CRAMER ! CO ! UK>
Date:       1999-09-30 9:59:13
[Download RAW message or body]

> On Thu, 30 Sep 1999, David Faure wrote:
> 
> > >  2) Using IDL will *always* create a certain kind of 
> bloat. Take the
> > >     OpenParts pixmap conversion for example...
> > Yes, but OTOH using QPixmap all over the place kills ANY 
> interoperability,
> > be it with Java, bonobo, c, perl, whatever.
> > Hence the idea of _using_ QPixmap for koffice to koffice stuff,
> > but keeping the IDL for interoperability.
> 
> Not sure I understand.. :-}

Well I don't have a fully ready solution at hand...
I'm just trying to bring the idea of keeping genericity and openness,
while still finding ways to optimize for the local case.
more below

> > > Another point:
> > > If you want to use XML to describe a GUI, then you *need* 
> > > direct access to
> > > the embedded component, like for accessing QAction objects 
> > > for example.
> > > You cannot use CORBA here.
> > Really ? I need to know more about this.
> > Can't you describe in XML "I want a menu with such and such 
> items, please
> > add it" ?
> > I suppose the problem is the callback when the item is pressed,
> > but that's where corba helps.
> > 
> > I really see good points in that mixed XML-CORBA solution :
> > you can add a lot of new GUI stuff in the XML format, so you
> > don't create IDL bloat for that, but you are still able to
> > communicate via CORBA to other languages/processes/machines,
> > to send the XML and to implement actions when menu items 
> are pressed,
> > when you need to redraw yourself, etc...
> 
> There are two issues, as you mentioned:
> 
> 1) callbacks
> 
> 2) at-run-time-modifications of the GUI
> 
> Callbacks *could* be covered via the SII/DII, so that you specify
> callbacks slot methods in XML. However this is ugly ;-)
If we have matter-of-taste considerations now... :)
I don't find this ugly at all, but that's just me :)
Describing GUI elements in XML makes it very fast, very extensible,
and programming-language independent, but that last point remains
true only if the callbacks are done through CORBA.

> If you want to modify elements of the GUI at run-time, then you need
> something like OpenPartsUI, don't you? This is where I think the
> QAction concept (which updates the GUI elements it is plugged in when
> changing action properties at run-time) and some limited direct-access
> to the toolbar/menus is the way to go. Everything else is probably a
> clone of OpenPartsUI.
I'm not sure I understand in which case we need that :)
You mean enabling/disabling, and updating a menu-item accelerator ?
If that's all the run-time stuff we need, it would be a VERY reduced
openpartsui, wouldn't it ?
And very easy to implement in other programming languages / toolkits...

Please consider very seriously how to keep the good aspect of the
current openparts, which is : interoperability.
If we work hard enough, we can solve all the bad aspects of it :
IDL bloat (->XML), crashes (->shared libs instead of processes),
slowness (->tinymico, avoid marshalling for shared libs), ...

I'm looking forward to embed Java apps in konqueror or koffice :)

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