From kde-core-devel Thu Sep 30 16:23:40 1999 From: weis Date: Thu, 30 Sep 1999 16:23:40 +0000 To: kde-core-devel Subject: The embedding thing .... X-MARC-Message: https://marc.info/?l=kde-core-devel&m=93870838307236 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