Re: gnome mdi dnd problem / GnomeUIInfo wrapping problem.

[Jaka Mocnik <jaka mocnik kiss uni-lj si>]

Andreas Kostyrka wrote:
> 
> On Wed, 1 Jul 1998, Jaka Mocnik wrote:
> 
> > Andreas Kostyrka wrote:
> >
> > > > I don't see how you could replace (e.g.)
> > > > gnome_app_create_menus_with_data by a macro that you put directly in the
> > > > arrays.  I use the function because it lets me set the client data
> > > > at runtime, not compile time.
> > > I know, it's problematic. I would have envisioned macros for building
> > > needed GnomeUIBuilderDatas. But keeping a separate _data function isn't
> > > good either: That means two functions have to be provided by anything
> > > using GnomeUIInfos, like GnomeMDI.
> > I think that the _data() functions should be kept for easy runtime
> > setting of the user data for callbacks while the _interp() could
> > probably be removed. As far as GnomeMDI is concerned, one will have to
> > find a workaround for this (one CAN of course use the create_menus
> > signal instead of supplying a GnomeUIInfo array). User data for document
> > specific menus MUST NOT be specified anyway, since the callbacks get the
> This is a ``Bad thing(tm)'' :(

I've changed this to use gnome_app_menus_insert() so that the user data
pointer is free to use for whatever you like (note that
gnome_mdi_child_set_menu_template() function does not create the menus.
the call is performed later on by GnomeMDI object). The active
view/child can be accessed from menu callbacks by using
gnome_mdi_active_view() & VIEW_GET_CHILD() macro. I hope this helps.

regards,
        jaKa

-- 
email: jaka.mocnik@kiss.uni-lj.si
w3:    http://www.kiss.uni-lj.si/~k4fe0026