[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:39:48
[Download RAW message or body]

Hi,

On Thu, 30 Sep 1999, David Faure 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.. :-}
> 
> 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...

Nonsense! You need to change the pixmaps of a ColorButton, need to
change entries in the font selection combobox or the font size combobox.
In KWord this updates may be needed after every press of a cursor key.
So it happens and it happens often. Just enabling/disabling .....
..... that must be joke, isnt it ?

> Please consider very seriously how to keep the good aspect of the
> current openparts, which is : interoperability.

Yes, cool. Imagine it is interoperability and nobody interoperates :-)

> If we work hard enough, we can solve all the bad aspects of it :
> IDL bloat (->XML), crashes (->shared libs instead of processes),

XML wont take away the bloat since you always need IDl interfaces
to modify the interface. Currently this is OpenParts, in Canossa
it is smarter and done with QAction.

> slowness (->tinymico, avoid marshalling for shared libs), ...
> 
> I'm looking forward to embed Java apps in konqueror or koffice :)

I am not. Ask Matthias Ettrich about the focus handling hacks
in Qt which are not in the AWT. That means basically: It was not and
is not possible to embed java stuff. Accelerators, focus etc.
will almost ever be broken.

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