Re: my nits

[Nat Friedman <nat helixcode com>]

Martijn van Beers writes:
 > On Sat, Feb 12, 2000 at 11:27:01AM -0500, Nat Friedman wrote:
 > 
 > >  > * 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.
 > 
 > yes, cute I guess, but it doesn't have much real-use value imho.

    Yeah.  It would be nice to include this kind of thing in a
BonoboApp-style toplevel object, though.

 > > 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.
 > 
 > I had some problems with that too :) So I created my own
 > work-around:

    Please let me know when there are problems like this.  We need to
make sure that Bonobo addresses the common use cases (I have been
reading UML books :-).

 >    #define VDEUIINFO_END   {NULL, NULL, VDE_MENU_BEFORE, FALSE, GNOMEUIINFO_END}
 > 
 >    typedef enum {
 >       VDE_MENU_BEFORE,
 >       VDE_MENU_AFTER
 >    } VDEMenuPosition;
 > 
 >    typedef struct {
 >       gchar *parent_path;
 >       gchar *relative_to_sibling;
 >       VDEMenuPosition pos; /* put this item before or after its sibling */
 >       gboolean override; /* override an existing menuitem. mostly used for
 >                             submenus */
 >       GnomeUIInfo data;
 >    } VDEUIInfo;

    This is interesting.  Can you please forward this code to the
list?  How components determine the position of their embedded
menus/toolbars is an open question.

 > > I would like some kind of Bonobo proxy for GtkSignals though.
 > 
 > What exactly do you mean by this?

    I mean that a BonoboObject can raise signals which clients can
catch.  So if you have a BonoboObjectClient or a BonoboControlFrame
you can get signals from the remote object/control which show up as
GtkSignals.

 > >     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.
 >
 > I don't think it's an issue of CORBA interfaces being hard in C. CORBA
 > just doesn't understand aggregation. each interface is its own object
 > in bonobo. CORBA doesn't even know they are connected.

    Of course.  This is not what I meant.  What I meant was that
people are not enthusiastic about using the CORBA interfaces from C,
and would therefore rather get a pointer to the associated GtkObject
when they are local.  Of course, I understand that there are other
reasons to get a handle to the GtkObject, but I think the need would
be significantly reduced if there weren't an aversion to using the
CORBA interfaces from C.

 > I'll try to write something up that does this.

    Ok, great.

Nat