From: Dom Lachowicz (domlachowicz@yahoo.com)
Date: Tue Feb 25 2003 - 11:31:01 EST
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/
This archive was generated by hypermail 2.1.4 : Tue Feb 25 2003 - 11:36:46 EST