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

List:       kde-core-devel
Subject:    The embedding thing ....
From:       weis <weis () stud ! uni-frankfurt ! de>
Date:       1999-09-30 16:23:40
[Download RAW message or body]

Hi,

I think that there are some errors in the current discussion:

a) konqui <-> koffice
   That is like comparing apples and eggs. Both have different demands:
   koffice has MANY plugins, uses this broken and damn slow QPicture
   hack. If you have 100 formulas, you can not have 100 widgets. That
   is too slow and KWord can not handle it very well.
   The QPicture approach means transfering lots of data between processes
   and eats memory. So please stop saying: Konqui works -> koffice must,
   too, unless you have more precise arguments.

b) CORBA and XML
   Nonsense! Creating a GUI is one thig. But a GUI lives, has to be
   updated, pixmaps of ColorButtons changed, bookmark menus extended etc.
   Canossa uses XML only to arrange the actions in mens, toolbars and
   submenus. XML in Canossa does NOT talk about menuitems, button,
   comboboxes etc. That is up to QAction. When you use CORBA and XML
   then you need a complete IDl wrapper for Toolbar and Menubar, otherwise
   you can never modify anything.

c) CORBA and shared libs
   Makes no sense: When you use shared libs, you kill the ability to
   distribute components (nobody needs/uses that anyway) and you can
   not link in a Java interpreter that easily since you would have to
   merge Qt and Motif. You can not link in some GTK stuff for the
   same reason. So there is no benefit in describing the interface
   for shared lib components in CORBA. It is only bloaty.

d) Large data
   Imagine an image filter which has to work on a 4MB QImage.
   Shared libs wont help. You still have to put the image in
   something that you can describe in IDL and that is for shure not
   a QImage. of course you can try to hack that in cuteidl, but these
   problems appear with all kind of classes with much data and you
   can not always play with the language binding.

e) Stability
   Crashing a distributed system correctly is a kind of art.
   When one component fails it should free/stop/kill all related
   components. But our CORBA stuff does not do that. if some KWord
   that embedded a KSpread crashed, then it may happen that KSpread
   survives or crashes. If the KSpread server is shared than it
   should NOT crash, if it is not shared then it MUST stop :-(
   But still we dont have that under control very well. Putting
   stuff in a shared lib helps, since the shared libs crash with
   the rest of the application. Remember the KDE0.x problems
   with kioslaves eating all CPU time. Some nasty CORBA servers
   may do the same after some partial crash.

f) Speed
   Compare embedding in canosse and koffice and then we are done on
   the topic.

g) Printing
   Passing around a QPainter in Canossa is a cool thing. Currently
   we pass around QPicture which is not supported in Java currently :-)
   the QPicture approach is bad as I showed above.

h) Static XML GUI
   As i already said: QActions can modify the menu items, or their
   widgets inside of toolbars at any time. No XML us used to describe
   the appearance of actions. XMl describes only ther order in the
   menus/toolbars.

i) Interoperability
   As outlined above this is currently with CORBA not the case. QPicture
   and focus handling make it hard to use another language/toolkit.
   And until now nobody ever wanted to implement a OpenParts binding
   in TCL or whatever. So I think we dont need to shoot ourselfs
   in the legs for a feature that actually nobody is using in practice.

j) Distributed KOffice
   Only people who are ill in the brain distribute koffice
   components on different servers :-) So we dont need that

k) KOffice embedding sucks.
   Yes, it does. It does since 1 year or so and nobody fixed it.
   And as a matter of fact nobody really uses it. So it seems unlikely
   that it will become fixed in the next few days. If it had been that
   easy, why did nobody try it with success before ? And nobody can
   say that there are no attempts.

l) Easy to use APIs
   Bad APi -> nobody learns it -> no code -> Does not matter how powerful
   the API is since no code uses it :-)
   This is OpenSource. We can not force people to learn OpenParts and
   for understandable reasons almost nobody did.

I could add more, but I am tired.

Let me sum up what I want:
I want a pragmatic approach. I dont care about technical visions and
interoperability and all that cool stuff. I dreamed this dream much too
long. The OpenParts/KOM/CORBA stuff is developed since over 1 year
and mico even longer. In contrast it took me 5 nights to write
canossa and convert KSpread to it. And it took me two more
nights to convert kofficelibs and convert KSpread again to the
new kofficelibs (done last night).

Lets face it: The 5 day work impressed many developers more than
the result of over 1 year with CORBA is able to do.

There is a lot you can do with CORBA, but lets concentrate what
99% of the people need:

1) fast embedding ->Canossa
2) easy APi for hacking ->Canossa
3) fast printing ->Canossa
4) embedding lots of formulas without the MS-Word effect ->Canossa
5) want up to date GUI APIs and not some wrapper that is not
   up to date ->Canossa
6) System-Reliability: Apps may crash but the system may not.
   But as outlined above crashing distributed systems is a problem
   ->Canossa

What people currently dont seem to need (they only like to know that
they could if they ever wanted to):

1) Interoperability with other fancy languages ->CORBA
2) Distributing an office app over several machines ->CORBA
3) Embedding components of other fancy GUI toolkits ->CORBA

See what I mean? The pros of CORBA are technically interesting
but actually nobody seems to make use of it. After more than
one year nobody every used it, so what ?

I think canossa is the way to go. We keep CORBA for scripting
of course and for communicating with shared servers like
kmail, konqui etc. Even components like KSpread etc.
keep their CORBA interface for scripting.

But when it comes to the constructions of a GUI then pure
C++ and KDE/Qt is superior by far.

Please mind this difference:
a) Scripting and remote control etc: CORBA is the way to go
b) GUIs: Qt/KDE + C++

You can not say wether CORBA or pure C++ is the best. It depends
on what you do. So why not use the best of both worlds as outlined
above ?

Bye
Torben

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