my nits

[Nat Friedman <nat helixcode com>]

Hi Martijn,


Martijn van Beers writes:
 > hi,
 > here are my questions/nits about bonobo as promised :)

    Thanks.  I'm really working hard to get Bonobo into shape in the
near future, so please get your complaints out now.

 > * there's still gnome-*.idl files in the idl dir ;)

    Really?  Oops :-) I'll fix this.  Thanks.

 > * Bonobo::Desktop isn't obsoleted by nautilus?

    bonobo-desktop was a cute hack by Miguel to make your window
CORBA-controllable, so you could write a perl script and move the
thing around and resize it and so forth.  What I'd really love to do
is to create a BonoboApp which subclasses GnomeApp, exports this
interface, and makes all of the UIHandler stuff more or less
automatic.  Unfortunately this is pretty difficult given that GnomeApp
is not written in a subclassable way.  My next commit will include
some nice improvements to the UIHandler usability though, since I am
at the point of getting daily complaints about that code.

    So, no, Nautilus does not obsolete Bonobo::Desktop.   There is the 
question of whether or not Bonobo::Desktop works anymore, though; I
can't find a test for it.

 > * Bonobo::AdviseSink is going to be used at all? It doesn't seem needed
 > so far, and the event service is probably a nicer solution anyway.

    I don't know if we want to use the CORBA event service; it is
somewhat complex (from what I remember reading a few months ago).  I
would like some kind of Bonobo proxy for GtkSignals though.  I don't
think there's any real harm in leaving the AdviseSink in there.  At
least it reminds us that we need a real solution to this problem.
Especially given that controls currently have no way of emitting
events to their containers, which leads to disgusting hacks like the
"activate_uri" method which I have been loathe to leave in for so
long.  So we do need a real mechanism for this kind of asynchronous
component communication, and I think a signal/slot setup is the right
way.

 > * open_stream in Bonobo::Storage has a mode parameter, but the relevant
 > functions in Bonobo::Stream don't have exceptions to signal that
 > you don't have permission for that operation.

    I see a NoPermission exception there.  What's the issue?

 > * I still think it would be nice if you could get the BonoboObject
 > pointer for an interface from another BonoboObject when they are
 > _add_interface()ed together.

    I agree; it's just a shame that it is so hard for us to use CORBA
interfaces from C, or we would not care about this at all.  This
should be a simple function; if you provide the code, maybe we can
work it in soon.

 > There's probably more things to be found when using bonobo extensively,
 > so I really hope there won't be a too strict api freeze for a while.

    That hasn't really been the Bonobo way.

Nat