JUN
10
2004

Total Eclipse

Yeah, it looks for me like deja vu: one day Sun introduced OpenOffice.org, more recently IBM presented Eclipse (development environment). Why I am talking about this here, you may ask?




I am not too big enthusiast of Java and Java-related tools/technologies, even if in ancient times I've tried IBM's Visual Age, for Java and Smalltalk, IIRC. However my work is somewhat related to 1) openoffice.org 2) Kexi (and also more-and-more reusing/sharing bits of KDevelop). So, I've subjective feelings about oo.org and Eclipse:

  • Both projects were developed/acquired in the past by a big players and let's be honest, both were a bit outside of the development maintstreamTM, at least in these companies' meaning.
  • Eventually, both companies had a choice to a) drop the project after many months of its dying b) opensource it. Both tried the latter way, and with relatively success. Both companies used their formerly-proprietary product as a part of their advertisement strategy (Sun even *pretends* that it's StarOffice is something very deferent than oo.org, while S.O. is often obsolete compared to current oo.org, and commercial offerings e.g. like OpenOfficePL).
  • SO what's wrong with this? Both projects were developed (not from the very beginning) to be portable across operating systems. Thus, both projects become more and more bloated, used less-and-even-less OS-native components (something what was good for MS DOS-like OSes :), but not wanted anymore after 80's).

Now interesting part: what's related to KDE:

  • On the FOSS 'market' oo.org and Eclipse at least potentially competes with KOffice and KDevelop; both sides have its advantages (bloating vs inmaturity, smaller feature set or KDE-dependence); both have areas that really cannot shine: 1) KDE's Office cannot play well with, say, MS OLE, without breaking KParts design by using wrappers-to-wrappers-to-wrappers-to-wrappers (what oo.org does) :) 2) oo.org can integrate with underlying desktop environment only with some GUI bits and minor newbie-visible components (as Ximian shown), but it's API (7 tiers, or so) is just black magic, incompatible with any desktop environment's native API without ugly wrapping (I was surprised with CuckOOo, for example).
  • Both oo.o and Eclipse, as software packages, are internally built as set of components somewhat interrelated each other via plugins. This is good, although these plugin frameworks are specific for the given project (e.g. UNO for oo.o -- while advertised as general purpose framework, I am not aware of well-known external projects developed using UNO). On the other hand, If I would be average user, I can at least discover that KDevelop uses the same source code editor and terminal emulator as is integrated with many other KDE apps. For typical Joe User, this is what integration means. Of course KDE Developers can found useful many more examples in KDE Libs' interfaces.
  • More on plugins. See Eclipse Project Slide Presentation, page 8 and so on. Kexi has similar architecture "almost everything is a plugin" like Eclipse, except I cannot see Eclipse plugins integrated somewhere else within desktop environments (because these environments already have their frameworks, eg. KIO / GnomeFS).
  • Oo.o and Eclipse have it's own settings/configuration cache/framework built in (ah, Mozilla/XUL has it too, btw) -- again: all this is custom, not reused, external developers are not familiar with these frameworks. Probably these projects could use more stuff from freedesktop.org (ok, however there are still many specs to add). For now, Eclipse reinvents what KSyCoCa / KConfig, (or Gnome's cache) already does, oo.o has its own set of xml files and its own conf. strategy as well. IMHO this is mostly because oo.o and Eclipse are children of projects developed in really other situation in the IT universe.
  • On page 14 of the presentation: Eclipse has plugins management and cross-plugins dependencies. Good. That's way like in we're designing Kexi. KDevelop has managed plugins per-language, as well. Right, Eclipse is here and is working, but it's valuable to show we're starting to have even more mostly-incompatible applications on Linux/Unix platform. And looks like none of them will dissapear because each has other objectives and 'market niche'. Just similar as on win32 or MAC OS X... At least, good that there are OASIS specs (hmm, do we have something like this for KDevelop/Eclipse?).
  • Finally - there are many other areas where both oo.o and Eclipse increase redundancy in our Desktop OS: i18n, widgets (and even low-level pixmap painting!), language engines (Eclipse is shipped with IBM's Java, AFAIK at least by default; oo.o has Python bindings but requires internal compiled-in python interpreter). Shortly, these designs are monolythical.

I am here not to beat great Eclipse and oo.o projects. Design decisions in these projects were also biased by compatibility requirements (eg. oo.o's scripting module is real functional ripp-off of MS Visual Basic for Applications, while oo.o API is highly incompatible with MS Office API, so more advanced scripts are not portable betweeen VBA and StartBasic engines, and in slowly incoming (in oo.o 2.0) MS Access replacement will be complete MS Access' ripp-off as well). IMHO, this one and reasons I've mentioned above are also our gothas to remember, within KDE subprojects.




Funny, but there is a threat that one day Kexi will have to add some redundancy to the desktop OS (if it's to be workable not only on KDE but as Qt-only app, e.g under Gnome) to provide functionality like better portable binary plugins, making binaries out of projects, etc. However even then, I hope that redundancy can be greatly reduced.

Comments

Due to the huge code base that follows from a monolythical design Eclipse now takes a full 3 minutes to start on my 800Mhz machine.. (which has plenty of memory).

The usability of kdesigner is better then the usability of eclipse IMO (my opinion meaning little to many, but I AM a usability expert...). Even with korganizer having a LOT less users.

In my opinion; a good framework like kdelibs is the only thing that allows project to mature fast and to add features in a sensible manner.


By Thomas Zander at Thu, 06/10/2004 - 11:49

The idea of KDE is to have the DE framework, and applications using that. An application not using the full KDE framework is not really a KDE application, so it looses interrest for KDE users because it is less integrated.

I like KDE, I use KDE applications primarily, whereever I can find them, and this works *very* well for me. If kexi choses to become a non-kde application, I will have not reason to prefer it over other database application GUIs, I may use it I don't find anything better.

Btw, I can't see why an application should be in KDE cvs and part of KOffice, unless it strives to fully utilize the KDE framework -- it would be kind of a lie, actually.


By KDE User at Fri, 06/11/2004 - 15:43


>I like KDE, I use KDE applications primarily, whereever I can find
>them, and this works *very* well for me. If kexi choses to become a >non-kde application, I will have not reason to prefer it over other >database application GUIs, I may use it I don’t find anything better.

In requirement analysis there is nothing to like or dislike. Particular technologies are chosen for many reasons, not just this subjective one. You probably a bit misunderstood my text, which is in fact more an ANALYSE OF CURRENT SITUATION for small fraction of the FOSS world. See below.


>Btw, I can’t see why an application should be in KDE
>cvs and part of KOffice, unless it strives to fully
>utilize the KDE framework – it would be kind of a lie, actually.

Hmm, who told you Kexi doesn't utilize KDElibs? It's a lie :) Look at the sources or developer's documentation.

And now btw:

The sentence about having Kexi Qt-only can be hard for you to understand without knowing real onbjectives for that. Let's say again: it's more like QKW on Linux than just Qt-only, what means that only small fraction of KDE (mostly KDElibs) should be required for, say, GNOME users to have Kexi available. More, this is also small hint for Linux distributors, to let users easier install such a stripped-up "minimal KDE subsystem".

Note that many lower-level application's layers do not utilize KDE or do it only a bit (eg. only uses KConfig, Trader, etc.). A good example is KexiDB module. All this can be wrapped to allow also non-kde version of application that uses these module.

And yes, this is related to hard question about having GNOME and KDE _not unified_, but more compatible each other.


By Jarosław Staniek at Fri, 06/11/2004 - 17:26