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

List:       kde-core-devel
Subject:    RE: More thoughts about embedding
From:       weis <weis () stud ! uni-frankfurt ! de>
Date:       1999-09-30 15:34:55
[Download RAW message or body]

Hi,

On Thu, 30 Sep 1999, Simon Hausmann wrote:

> 
> 
> 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.. :-}
> 
> > > 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 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 could not have explained it better :-)

Bye
Torben

> Ciao,
>  Simon
> 
> 

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