path in items was Re: gettext domain(s) and Bonobo

["Sergey I. Panov" <sipan mit edu>]

On Thu, Jan 06, 2000 at 02:01:30AM -0500, Nat Friedman wrote:
> 
>     We do not want Bonobo to depend on gnome libs 2.0, so moving these
> things from the UIHandler to Gnome Libs does not serve Bonobo's
> purposes well.

 You can move them out of UIHandler and then get rid of them when they
are in released gnome libs foo.0

> and that we should define the "Gnome 2.0 API" as:
> 
>         Bonobo 0.foo
>         GConf  0.bar
>         Oaf    0.baz

  Not everyone whould want to use CORBA (read Bonobo) in their gnome
applications, so non-Bonobo UI stuff should eventually be moved out.
If it is not, you would have two different API -- gnome-lib and bonobo.
  
> And so on.  But that's not really germane to this discussion.

 -------------------------------------------------------------------

        
>     As for the translations, we translate the label strings the user
> provides in the translation domain of the application.  Please note
> that paths do not get translated, as they are supposed to uniquely and 
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> universally identify a UI element.
>
>     The only time that you will want to translate an item in the
> domain of Bonobo is for "standard" menu items, like the GnomeUIInfo
> macros in gnome-app-helper.  Currently, the only way to generate these 
> standard menus using the UIHandler is to convert the UIInfo structures 
> to GnomeUIHandler[Menu/Toolbar]Item structures and create the menus
> and toolbars like that.

 The problem is that GnomeUIHandler[Menu/Toolbar]Item created (out of
UIInfo) with the empty path and the translated label. You would have
to add "relative path" == "u-stripped original label" field to
GnomeUIHandler[Menu/Toolbar]Item to get around it. May be a path field
without "/" as a first character shold be treated as "relative
path"(relative to the root of the current tree.

>  > 	This solves a scad of dynamism problems since the container
>  > hierarchy can cope well with sub-widget removal. I suppose something
>  > similar is neccessary for menus, but I get far less convinced there. This
>  > would also kill many thousands of lines of code from the ui-handler I
>  > hope.
> 
>     Uhm, it doesn't work with menus.  You really can't create a new
> GtkMenuBar for every component.  You'd get laughed out of town.
      
    ?!?!?!?!?! Why?

In MSWindows, menu bar is replaced by the activated OLE component menu
bar with the component icon on the left (just as if you container
was a Mac desctop) and replaces all toolbars with the component toolbars
(in some manuals they use "toolbar" for both "menu" bar and "button bar")


Best,
     Seregy