Bonobo is a library whose use is officially discouraged for new applications; see the release-team platform page. Most applications are actively ripping out dependencies on Bonobo; gnome-vfs even received approval to make a minor API/ABI change to remove Bonobo as a dependency. The rest of this page is some history from one person's point of view trying to explain and figure out what Bonobo is.
Bonobo is the component object model of the GNOME (Gnu Network Object Model Environments) project (it is also a monkey -- see Resources). Bonobo provides a COM-like model, using CORBA as a location-transparent transport. It is the foundation of the GNOME vision to provide a fully Free Gnu Network Object Model Environment. [Edit by Elijah: This was copied from elsewhere; I've read it in a few places. Note how this entire paragraph creates more questions than answers for most users and thus utterly fails at explaining what Bonobo is.]
What Bonobo is
What Bonobo is There are several helpful orthogonal ways of looking at what Bonobo provides, namely there are three distinct functions:
- Interfaces define Bonobo. They are specified in standard CORBA IDL, and they are independent of language, system libraries and platform.
- Wrappers define C 'sugar' interfaces, which ease some of the issues of using CORBA from C, especially as concerns integration with Gtk+ (the GNOME widget system).
- Implementation is the guts behind the interfaces. Implementation provides the functionality that can be invoked via the CORBA layer. While it is possible to implement the Bonobo interfaces in any language, the GNOME implementation is sufficient and Free.
Another way of looking at Bonobo is that it assists in the implementation of:
Controls provide basic visual embedding. They are used to provide single view "rich widgets," customizable via property interfaces (much like an Active X control or JavaBean).
- Components have an implicit document/view abstraction, and are suitable for embedding in productivity applications.
Compound Document Support
- Compound Document Support assists in the management of compound documents. Many supporting interfaces are provided such as structured storage, printing and monikers for linking.
I understand that there is some sort of evaluation of Bonobo going on.
Several years ago, I was inspired by MDI's talk, and looked into Bonobo. But for the life of me, I just couldn't make heads or tails. I wondered if it was just me- but I found that most of the people I talked with couldn't make heads or tails of it either.
I kept finding myself in front of 500-1,000 page books about CORBA, scratching my head. I got the stubs, the skeletons, I understood those ideas. But somehow, when I sat down to code, it just seemed like an amazing labyrinth, to get a "Hello, World" to run. If it was so hard to do that, how hard would it be to make a useful component this way?
When I looked around, I realized that it seemed that only the Ximian or Helix guys knew how to use it. I reasoned that, internally, they were probably teaching each other how to use it. But externally, nobody seemed to really know what to do with it.
Time passes, and here we are today. It seems that people now want to use D-BUS for their work.
I can understand why; Looking over the pages, I see that development of the idea is happening out in open, that implementation is happening out in open, that it's clear who I can talk with, where to find documentation, and all these wonderful things.
However, I only pause, because MiguelDeIcaza expressed some technical reservations, when I met him briefly. He seemed to feel that it was good for what it was for, but that it wouldn't work in all places. I assume he was referring to IPC communications, and I believe he felt that Bonobo covers many cases that people naivly want to use DBUS for.
Now I look into Bonobo again, and see that, while it still seems under-documented, there appear to be places where I can use it, and make a difference with it.
For example, there's this Bonobo Tutorial for Python. It appears to be good documentation, something that a human could actually use.
Is there a "Bonobo explorer?" I haven't seen one. When you get Visual C++, you get a COM component explorer, a DLL dependency explorer, all sorts of wonderful things. Are there analogs here for Unix and Bonobo? If so, wouldn't you think that they should be part of some major distributions, under the "Programmer's Packages" category?
Do I need to write the "Bonobo explorer?" Looking over this article, it doesn't seem terribly complicated. I see that we can pull a list of bonobo components, and list out their properties. It should be pretty simple to make something in PythonCard that does this, then. Is the reason we don't have one simply that LionKimbro hasn't written one? And is this, simply, the reason why Bonobo hasn't taken off?
In my experience, programmers do not like to read 1,000 pages of documentation. They would rather just pop the hood and see what everything does. It seems that people have written a few 100 pages of documentation for Bonobo, a bit short of the requisite 1,000. But it doesn't seem that anyone's made it easy to pop the hood. Or, have I simply just not been looking around lately, or hard enough? Are there tools that you recommend I read, in order to learn about Bonobo?
If Bonobo is right, and if Bonobo is what we already have, and if it does some things that D-BUS does not do well, then I would think that we should keep it, document it, make the necessary support tools, and all these things.
-- LionKimbro 2005-04-16 23:30:43