Re: Commit: some bonobo work

["Gustavo J. A. M. " Carneiro <gjc inescporto pt>]

On Ter, 2003-02-25 at 17:04, Michael Meeks wrote:
> Hi Dom,
> 
> 	Thanks for your comments, some of which are easy to answer, and others
> are more interesting :-)
> 
> On Tue, 2003-02-25 at 16:31, Dom Lachowicz wrote:
> > 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)"
> 
> 	Right - so you have to find someone who will take the code; it's not
> libbonoboui; perhaps it is 'gal' or gnome-office-libs or some other such
> place, I've no idea.
> 
> > For applications like Abi and Gnumeric, being able to
> > print is essential.
> 
> 	Clearly; the thing is - the amount of code is in fact so small, that
> this thing is easily cut & pastable - at least, from what I remember of
> writing it.
> 
> > Sure, I'll write up better content negotiation Persist
> > and PersistFile interfaces and send them to you.
> 
> 	We should do it as an extension, so we're bin-compatible (and/or a
> separate aggregated interface) - it'd be great to have though - for
> sure. I believe we had a list of supported mime types in getContentTypes
> - but AFAIK only evolution ever really used that (for the gtkhtml editor
> component).
> 
> > > 	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.
> 
> 	Great :-) it's nice to have your input.
> 
> > 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.
> 
> 	Well - we have most of just such a magic-like method; you currently
> have to do:
> 
> 	pb = bonobo_property_bag_new (NULL, NULL);
> 	pspecs = g_object_class_list_properties (
> 		G_OBJECT_GET_CLASS (my_object), &n_pspecs);
> 	bonobo_property_bag_map_params (
> 		pb, my_object, pspecs, n_pspecs);
> 
> 	So it should be trivial to hack up a convenience method to do all of
> that in 1 shot; call it 'bonobo_property_bag_new_for_gobject' and feel
> free to commit to HEAD libbonobo; [I've just branched it for you].
> 
> > Should have a working, implemented print interface
> > situated within Bonobo proper or GnomePrint.
> 
> 	In which case GnomePrint - but as I say; this decision is entirely
> political; you may have more luck getting it into libgnomeprintui -
> Chema ?
> 
> > 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.
> 
> 	Uh ? ContentType is a typedef for a string, which contains a mime-type,
> so ... I'm not quite clear what's up there.
> 
> > 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.
> 
> 	Well - the CORBA_foo types are in the spec; and better - they cause no
> real pain, you can automatically cast between gdouble and CORBA_double -
> they're all just typedefs of 'double' anyway ;-) [ CORBA_boolean as a
> guchar equivalent vs. gboolean == int is one gotcha for var-args, but
> ... can't do much about that now ].
> 
> > The kicker: Bonobo 2.0 API documentation should be
> > hosted on http://developer.gnome.org/doc/API/
> 
> 	That sucks - Gustavo did a load of work making the docs really good,
> adding diagrams, more text, you name it - they should rock; it's a shame

	Well, I didn't really add much more text, I just converted some pure
text files to docbook ;)

> they're not on that page. We should make noise at whomever maintains it.
> Gustavo any chance of posting a link to your copy as well?

  http://spectrum.inescn.pt/~gjc/gtk-doc/html/libbonobo/
  http://spectrum.inescn.pt/~gjc/gtk-doc/html/libbonoboui/

  However, this is my PC. Please don't hack it, and please don't put
these links on developer.gnome.org! :)
  But I do think developer.gnome.org needs updating. Someone bothered to
update GTK+ and friends docs, but there aren't _any_ GNOME 2.x docs
online. This is terrible!...

  Another thing that is wrong is the sgml docs. We need to standardize
on XML docbook 4.1.2, because jade is obsolete and some people (like me)
don't even have the tools to generate docbook 3.x from SGML. We need to
get all modules to use the same tools, otherwise it becomes difficult to
maintain. James Henstridge was working on a standard Makefile for
handling gtk-doc, which is good... This is becoming a bit offtopic,
sorry!

> 
> >  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.
> 
> 	Heh :-) that's fine - it's great that you're using bonobo to the extent
> that you notice these things, and are prepared to do something about
> you.
> 
> 	Good to have you around,
> 
> 	Regards,
> 
> 		Michael.
-- 
Gustavo Joćo Alves Marques Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>