Re: Commit: some bonobo work

From: Dom Lachowicz (
Date: Tue Feb 25 2003 - 11:31:01 EST

  • Next message: Dom Lachowicz: "Commit: IE_ImpInserter class"

    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

    > > 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

    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,

    Do you Yahoo!?
    Yahoo! Tax Center - forms, calculators, tips, more

    This archive was generated by hypermail 2.1.4 : Tue Feb 25 2003 - 11:36:46 EST