From kde-core-devel Sat Dec 14 20:13:35 2002 From: Havoc Pennington Date: Sat, 14 Dec 2002 20:13:35 +0000 To: kde-core-devel Subject: Re: Looking for feedback on Gnome/KDE article X-MARC-Message: https://marc.info/?l=kde-core-devel&m=103989684516799 On Sat, Dec 14, 2002 at 12:39:23PM +0300, Vadim Plessky wrote: > as about OpenOffice: well, 2 years ago GNOME people promised to > "disassemble OO into parts/objects, make BONOBO objects out of > those, and assemble those objects back into one great Office Suite". > It seems this hasn't happen. Why? I really curious to know thier > answer. If you can get some answers - pls post them back to the > list, or send off-list. Because no one with a clue thought that was a remotely feasible thing to do. OO is 6 million lines of code. I would be careful what you take to be a "promise from the GNOME people" ;-) as there are quite a few GNOME people. My memory is that some people thought they could build a Bonobo<->UNO bridge, and slowly migrate to a merged UNO/Bonobo over time. That could perhaps be done, the rationale is that UNO is about the nicest free software component system short of a full CLR. But no one with the faintest clue thinks OO can be quickly or easily ported to native widgets, though it could be done with a lot of effort. And the native-widgets GTK office people continue to work hard on their apps, which are IMO some of the best native widgets office apps out there, so there's definitely some disagreement on the right approach. The existence of WINE, VCL (OpenOffice), XUL (Mozilla), GTK, Qt, kdelibs/libgnomeui (which fork from GTK/Qt a good bit, though libgnomeui is actively being folded back into GTK and thus shrinking, maybe kdelibs is too), and more, just points to the importance of well-defined library-independent specifications for interoperability. Reimplementing everything with the One Grand Unified Toolkit is a pipe dream. And if you ever achieved it, someone would come along with a better toolkit anyhow. Microsoft keeps replacing theirs, plus you have everything from OWL to Qt on Win32. That's why we have something like fontconfig, which defines the set of fonts that each toolkit should display; this way we transparently get the same fonts regardless of higher-level libraries used. Mozilla, Qt, and GTK have all adopted it, and OO will be along eventually. By increasing modularity and orthogonality we allow for more innovation. We can change one part without changing all the others. i.e. "the grand unified font system" is a much better thing to have than "the grand unified library that does everything" - modularity good. If we ever get the platform mostly unified, it will be by creating a series of well-defined common specs or implementations along the lines of fontconfig, such that the top layers such as GTK and Qt become smaller and delegate lots of their functionality. This gives us a gradual migration to platform consistency and de-bloat as the right answers become clear, instead of dreaming of wholesale conversion of huge codebases. Qt, GTK, WINE, Swing, XUL, VCL are willing to adopt a well-specified standard feature, when they aren't willing to link to libgnomeui or kdelibs. Re: fejj's advogato diary that Guillaume pointed to - nothing revolutionary there, it's an argument that most of the core GNOME developers have been making for years. Matthias Ettrich can tell you that Owen and I quietly circulated a proposal for a primarily in-process (not network transparent) cross-desktop component system 2 years ago, it's dated December 2000. What fejj proposes is a simple dlopen() of a lib containing a GObject - similar to KParts - which most people would not consider a "component system" in the same way that COM/XPCOM/UNO/Bonobo are component systems. The book "Essential COM" has a first chapter that goes into what makes COM a "component system," if you're interested. But this is just arguing over what words mean; the dlopen() approach is certainly a reasonable way to get 85% of the functionality and it's easy to implement. Nothing wrong with that. My opinion is that the whole free desktop community should be actively working on two things in this area for the future: a) a simple IPC/messaging system, DCOP-like in scope, over the next year or so - I would like to see us have this by Dec 2003. b) longer term, say 2-3 years out, a toolkit-independent solution in the component system or CLR space. i.e. dynamically loadable, fully encapsulated (no private ABI), dynamically introspectable cross-language objects. This is not primarily a GUI system, components are not primarily embedded widgets and in fact one of the main driving forces here is likely to be web applications. This gives us an IPC system and a component system, which are separate, not the same. Bonobo does not get that right. But Bonobo does get some things right, for example I think trying for a full component system (handling language bindings in a fully automated way, and fully encapsulating private ABI) is a good idea in the end. Joel's recent comments are very appropriate. See http://www.joelonsoftware.com/articles/LordPalmerston.html, a quote: The huge surface area of all these worlds of programming leads to pointless flame wars over whose world is better. ... People who only know one world get really smarmy, and every time they hear about the complications in the other world, it makes them think that their world doesn't have complications. But they do. You've just moved beyond them because you are proficient in them. These worlds are just too big and complicated to compare any more. Anyone who starts telling you about how GNOME or KDE or Windows or Delphi or GNUStep or Amiga or *whatever* is the greatest thing ever in every way, should be dismissed out of hand. We need to be discussing the details and specifics, both pros and cons, and using all the experience that we've gained by trying multiple approaches in various projects. i.e. harness all the expertise of the whole free software community. Core developers are too scarce to ignore some of them. The faster we can drive well-understood "commoditized" problems down into common well-documented modules, the faster Linux (and UNIX) will move forward on the desktop. Anyway, just some thoughts on this whole thread. Havoc