Re: GNOME and .NET

[Michael Meeks <michael ximian com>]

Hello Ian,

	Let me try and straighten out some of the more acute misunderstandings
in your post.

	Let me start, by re-asserting that you have 1 point that I agree with
(amidst the myriad things you say) and that is this:

	"Use Bonobo for what it's good for"

or conversely

	"Don't use Bonobo for what it's not good for" :-)

	ie. Instead of trying to use it for super fine grained objects, use it
at a far more sensible and granular level - that of the control for
example. Yes if you insist on making every boolean a BonoboObject you
will get performance issues :-)

	Notably the same is true of GObject - if you insist on mis-using a
technology - it is not reasonable to then go and complain that the
underlying technology is broken :-)

	This is not really breaking news, go read eg.

http://mail.gnome.org/archives/gnome-hackers/2001-September/msg00107.html

	For a considered view from the massed ranks of RHADL & myself. See the
sections 'Reasons to/not to use Bonobo' and the 'Conclusions on Bonobo'
for example.

On Sun, 2002-02-03 at 01:31, yakk-gnome-hackers yakk net wrote:
> I knew that would provoke a response from someone - well, I knew it
> would provoke a response from you :)

	Well - I hope you've failed to provoke me - nice try though, you got
pretty close.

> I just keep hearing about applications that are having bonobo removed
> from them in the port from the gnome1 to gnome2 platforms.

	Interesting - I don't. I hear about people moving the cut where they
put bonobo to somewhere sensible - perhaps the Control level.

> Bonobo seems to make APIs harder rather than simpler (take a look at
> the proposed API for Jacob's bonobo-based file selector and tell me
> thats simple).

	Well - there is a grain of truth in your point. It certainly makes APIs
different to what people are used to; but in a fairly inevitable way.
But I'd welcome any _constructive_ input on these issues, I'm doing my
best to make it easy to use.

> Bonobo seems to add slowness to applications (silly stuff like
> base64ing every ui string all the time seemed to be at the top of
> Nautilus profiles last time I looked).

	Interesting; given that there is no base64 encoding of any string
inside the Bonobo 1.0 UI handler, I suspect you have been coding too
long :-) [ we hex encode strings to work around, acute, libxml1 encoding
breakage that was not anticipated at the beginning of the design -
regrettable ]. In Bonobo 2.0 we not only junk libxml nodes as a model
(very memory hungry) but we also drop the need to encode strings.

	But dudie - if you want to see a bonobo pixmap stringification API
showing up in the nautilus profile try reading this:

http://lists.eazel.com/pipermail/nautilus-list/2002-January/006963.html

	I can't claim any particular skill in finding such things, beyond
having implemented the CORBA method trace in ORBit2 and it jumping out
at you like a multiply hammered thumb. Perhaps it is such 'bonobo'
inefficiency and slowness that pains you ? ;-) I look forward to the
next round of Nautilus 2.0 profiling.

	Similar things in Nautilus such as doing the same (huge) oaf query
multiple times result in nice speedups too (when cached) lots of such
things have been fixed in Gnome 2.0 - resulting in significant user
visible speedups.

> Bonobo is to blame (according to applications developers I talk
> to) for strange UI inconsistencies (notice how the keybindings in the
> menus in Evolution's compose dialog are wrong if you've customized the
> keybindings for the gtkhtml component through the capplet). All this makes
> me think that Bonobo isn't working out for GNOME.

	Do you have a bugzilla bug for this ? or is this just silly griping ? -
I hear there are oh ... all sorts of bugs in - wait what project are you
involved with ? ;-)

> The other aspect of the failure seems to be personal/political. Bonobo
> doesn't use GNOME function / object naming conventions.

	Are you trying to re-provoke the stdlyCaps debate ? grief - you're
trying hard to sow discord. Of course, for all non CORBA methods we use
the GNOME function & object naming conventions.

> Bonobo doesn't (last time I checked) use standard GtkObject/GObject
> ref/unref functions.

	Well; let me see - here is the g_object_ref method (essentially):

gpointer
g_object_ref (gpointer _object)
{
  GObject *object = _object;
  g_return_val_if_fail (G_IS_OBJECT (object), NULL);
  g_return_val_if_fail (object->ref_count > 0, NULL);
  object->ref_count += 1;
  return object;
}

	How do you suggest Bonobo 'uses' that ? I asked Tim to virtualize this
for us when he was designing GObject - and it never got done. But yes I
agree that it's highly regrettable that GObject, the ORB and Bonobo have
diverged instead of converged in Gnome 2.0 - partly Tim & my fault for
not talking to each other / playing with each other's stuff early
enough. I hope we can fix this in future, and if not that we can
inter-operate with eg. Mono nicely enough that it's no problem.

> Bonobo based UIs don't support the standard GNOME way of assigning
> accelerator keys to menu items.

	I'm unaware of any issues in that area at all - what are you talking
about ? Please, please do file such things in bugzilla when they are
found, don't leave them festering in the resentment bin.

> There was the Not Invented Here bonobo-conf fiasco.

	Grief; is the next question "Have you stopped beating your wife yet" ?
but wait I'm not married ( less than 3 months ! :-).

	Of course it's possible that this point isn't an unfair and
ill-informed dig - I mean, in it's very statement it contains
misunderstanding and vituperative - but please, re-phrase the question
in a less contemptible way and I will answer it.

	Incidentally bonobo-conf's "config:" moniker is a pure in-proc GConf
wrapper in Gnome 2.0, and is built into libgnome.

> I don't know if that makes it a complete failure but it seems that
> theres some serious problems with the technology at least and
> perhaps other problems too that are stopping people adopting it.

	Where I will agree with you - is that bonobo is a tool that people can
(and should) use to solve certain problems - it is not a tool that can
solve every problem - but it gives us a huge amount of power and
flexibility when used right. So use it right !

	[ naturally this applies to everything - please don't use an axe 	  to
cut your toe nails [1] ]

> Perhaps as a "core gnome module maintainer" I should give an interview to
> The Register about my opinions on Bonobo's future in the platform, but I
> thought I should bring it up in an appropriate forum first.

	Go for it; I think we can all use a laugh.

	Am I allowed to sigh here ?

		Michael.

[1] - "but you said it was the ultimate cutting tool" - man with no feet

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot