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

List:       kde-core-devel
Subject:    Re: The embedding thing ....
From:       Uwe Thiem <uwe () uwix ! alt ! na>
Date:       1999-09-30 17:32:18
[Download RAW message or body]

On Thu, 30 Sep 1999, weis wrote:

Wow! The master has spoken. Makes a helluva lot of sense to me what
Torben says.

Uwe

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

-------------------------------------------------------------------------
Uwe Thiem                                        Tel: +264 - 061 - 244511
P.O.Box 30955                                    Fax: +264 - 061 - 244511
Windhoek                                         Email:   uwe@uwix.alt.na
Republic of Namibia                                           uwe@kde.org
                                                       http://www.kde.org
                  **********************************
         You can still escape from the GATES of hell: Use KDE!
-------------------------------------------------------------------------

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