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

List:       kde-core-devel
Subject:    Re: More thoughts about embedding
From:       Simon Hausmann <shaus () uermel ! Med ! Uni-Magdeburg ! DE>
Date:       1999-09-30 8:40:50
[Download RAW message or body]


I think there are several problems when attempting to use an IDL
interface to create/connect to a GUI:

 1) Using IDL will *always* end up in a restricted solution, meaning
    developers will not be able to create/modify certain GUI elements,
    because they're either not defined in the IDL, yet, or they are too
    difficult to describe them in IDL (too much bloat)

    In the end this means that applications using this technology will not
    be able to use the latest features of Qt/kdeui and therefore
    possibly have a less-functional GUI than applications not using this
    technology.

 2) Using IDL will *always* create a certain kind of bloat. Take the
    OpenParts pixmap conversion for example...

 3) It requires developers to learn a "new GUI" system. This is bad IMHO,
    as there should IMHO be *one* interface for creating a GUI.

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.

That's my humble (and recently changed :) opinion.

Ciao,
 Simon

On Thu, 30 Sep 1999, David Faure wrote:

> I think we are mixing issues.
> 
> (The first part replies especially to Reggie's "embedding doesn't work in
> koffice anyway")
> 
> Sure, embedding doesn't work well in koffice currently,
> but konqueror is the living proof that embedding can work really fine.
> And you'll notice that it works very well with 'local views'
> (icon, html, text, ...) and somewhat well with remote views,
> (kview, ...) but not as well. Why ? Because servers are bad, I already said
> that.
> 
> What we need I think is to do the same in koffice : to embed using 
> the code in shared libraries, and that's going to work fine.
> We can know it because it already works fine in konqueror.
> 
> It might be that there are bugs in koFrame or koView that make embedding
> crash in koffice and not in konqueror - that has to be checked.
> (If it hasn't worked for a year, I think it's especially because we all
> use openparts and the koffice libs as if they were completely debugged,
> which is not exactly true).
> 
> My point is : let's not drop openparts, but let's make it reliable, by
> not talking to remote processes anymore.
> 
> About openparts : I don't really care about bonobo, but please realise that 
> keeping the current openparts IDL will make it possible to implement it
> in Java for instance ! I'm sure that unlike a gnome implementation of
> openparts
> that will never happen, a Java implementation of it is VERY likely to be
> done.
> Now - can that be done with canossa ? I don't think so (the menubar/toolbar
> stuff
> is exchanged in XML, no problem, but putting Java code in a shared lib isn't
> possible afaik, whereas we can use CORBA to talk to a Java process - yes
> different
> process here but at least there's a way).
> 
> What about a mixed solution, like using CORBA to launch the embedded view,
> but then using XML to describe the menubar/toolbar stuff ?
> That would allow to get rid of the openparts IDL, but to still keep
> all the advantages of CORBA (different languages, different processes when
> necessary,
> different machines...). And this way Simon and Torben will still be able
> to play with that XML stuff that they don't want to be deprived of :))
> 
> --
> 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]