Hi Michael, > > So, a bunch of bonobo interfaces went away and a > bunch > > more changed. > > It was thought in general that having unused and > crufty interfaces > lurking around was a bad move; if you need new > common interfaces it > seems better to prototype them in real use before > folding them into > libbonobo - I'm most interested in which you were > using though.
Well, my above sentence doesn't imply that the changes are necessarily a bad thing. Embeddable was garbage, and I'm glad to see it gone. Print was not garbage, and I'd really like it back. > As you can see - the remote printing interface is > still there; there is > simply no implementation of it - since that would > imply depending on > libgnomeprint - which is an unstable / non-platform > library. The Bonobo > printing implementation was in fact moved to > libgnomeprint - you might > consider badgering Chema about it. Gnomeprint 2.2 is an exceptionally stable library and if it isn't considered a "platform library", well, IMNSHO, it should be. The only mention of bonobo in the GP sources is: "* gnome-print-bonobo.[ch], gnome-print-bonobo-client.[ch]: remove as they are not used (yet)" For applications like Abi and Gnumeric, being able to print is essential. Being able to print your embedded compontents is essential. Being able to print as an ebmedded component is essential. I don't really care about the logistics of where the interface's implementation goes. Not having this in the 2.0 release was an oversight for application developers, no matter how one might want to explain it away. Is that your fault? Probably not. Does the end result suck? Yup. > > A lot of interfaces seem to have stayed (whether > they deserved to > > or not...). > > Any input no which ones didn't deserve to / > improvements much > appreciated - preferably on-list / in bugzilla. Sure, I'll write up better content negotiation Persist and PersistFile interfaces and send them to you. > > We now compile, but we can't be used as a Bonobo > control because we > > don't do the Bonobo activation magic. > > Uh ? that's really similar - you just change your > .oafinfo file to a > .server file, and ram it in > $(libdir)/bonobo/servers, should be a 10 > second hack. Don't take my not doing this as a knock on your activation architecture. Just I didn't have the time or ambition to investigate what was needed in order to get it working right away. Testing to see if the interfaces compiled and linked was trivial. > > We don't really implement PropertyBag either, but > we could/should. > > I'll work on that in the future. > > I think the thing to do is to sit down with Jody > and/or anyone > embedding your app, and come to some decent > agreement on what interfaces > you really need - I'd be happy to have some well > thought out new things > going into bonobo. I don't disagree, and we've already planned to do that. > > God, bonobo sucks worse than ever now. > > My impression is that shrinking the size, pruning > the cruft, making it > easier to use, etc. actually improved the situation > dramatically, but > hey ho - constructive criticism welcome. A lot of the cruft is gone, and I'm thankful for it. A few things that I care about are essentially gone. A few things that I care about are still crufty. A bunch of other decisions are suboptimal from my, a consumer of the library, perspective. Here's a few for you off the top of my head: Should be able to pass in a GObject to a convenience constructor and have it automagically construct a PropertyBag for it. After all, how different to an application developer are the get/set fns from the GObject ones, and how different are BonoboArgs from GValues. It should just be like magic. Should have a working, implemented print interface situated within Bonobo proper or GnomePrint. Persist and PersistFile should have a content negotiation method that more closely resembles the X clipboard mechanism. This might be a nitpick, but I, as an application developer, don't see the reason to have your own ContentType (even if it is just an integer) when mime-types, lists, and strings are so readily available. Ideally for me as an application programmer, as few CORBA_foo-like things would pass into my consciousness as possible, especially when they so closely resemble other glib datatypes such as gdouble, gint, gfloat, GError, etc... I think that more could (and perhaps should) be done behind the scenes. The kicker: Bonobo 2.0 API documentation should be hosted on http://developer.gnome.org/doc/API/ No doubt you have many exceptionally good reasons for doing things the way that they're currently done, and if I was in your shoes, I might not have done things any differently. In many ways, 2.0 is a much better product than what shipped in 1.4. Your hard work and effort are appreciated, even if my original mail didn't come off that way (granted that email wasn't meant for you at all, either). All I'm saying is that my life as a consumer of the Bonobo library could be easier and more fulfilling, and my previous email was just me griping. Nothing to see here. Move along, Dom __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
