Re: gettext domain(s) and Bonobo

[Nat Friedman <nat helixcode com>]

Michael Meeks writes:
 > 
 > Hi Sergey & others,
 > 
 > On Wed, 5 Jan 2000, Sergey I. Panov wrote:
 > > > The whole problem is fixed by fixing gnome-ui-handler in bonobo to
 > > > translate before it sends the information to its container
 > > > application.
 > >  I just noticed that there are parts in gnome-ui-handler that not
 > > CORBA/Bonobo specific and that they can be moved into new gnome-libs.
 > > I also noticed that translation can be done within that part and, as a
 > > result, you will handle translations(and some other things) in one
 > > place --- libgnomeui. In fact, libgnomeui itself can become a bit
 > > cleaner this way.

    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.  Bonobo's release schedule will remain independent of
gnome libs; I don't understand why people keep wanting to complicate
Gnome's headache-inducing dependency chart by throwing everything into
gnome-libs!  

    The Gnome-libs 2.0 security blanket has grown musty and
embarassing.  What I think should be done is that the individual
sublibraries should be kept separate (or made separate if not already)
and that we should define the "Gnome 2.0 API" as:

        Bonobo 0.foo
        GConf  0.bar
        Oaf    0.baz

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.

    In the future, it would be good to have a better mechanism.  It
has been pointed out several times that one problem with using macros
for these standard menu items (and a problem with these
structure-driven APIs in general) is that they don't map well to
scripting languages.

    So I would like to have a way to create standard menu/toolbar
items by path.  That is, simply by naming the path to the menu item,
you get the standard key bindings, pixmaps, and labels automatically.
The API might look like:

    gnome_ui_handler_menu_new_item_standard
            (GnomeUIHandler *uih, char *path,
             GnomeUIHandlerfCallbackFunc cb,
             gpointer data);

    gnome_ui_handler_menu_new_subtree_standard
            (GnomeUIHandler *uih, char *path);

#define GNOME_UI_HANDLER_MENU_STANDARD_SAVE "/File/Save"
#define GNOME_UI_HANDLER_MENU_STANDARD_EXIT "/File/Exit"
.
.
.

    The macros above would just serve as a convenience, to allow some
sort of compile-time feedback, in case you mistype a standard menu
path.  The long-and-short of it is that, with a system like this, we:

        1. Do the translation in the Bonobo catalog.
        2. Don't screw language binding people.

Now, onto Michael's complaints:

 > 	Argh, gnome-ui-handler is getting really, really bad. Also from
 > what I have seen gtk_toolbar's are not whatsoever designed to allow the
 > kind of dynamic removal / insertion that we are wanting to do. Come to
 > this neither is gnome-dock, and the whole thing gives me the heebie
 > jeebies which is perhaps why I've stopped fininshing it.

    Yes, GnomeDock, GnomeApp and GtkToolbar weren't really designed
for this stuff.  Besides which, GtkToolbar is lacking some important
functionality which we need (the sizing situation -- the way toolbar
buttons just get dropped if the window is too small -- is particularly
egregious).  The GnomeUIHandler code touches the GtkToolbar API very
little.  I think that it would not be difficult to switch to a newer,
better toolbar widget if one were made available.

    As for GnomeApp and GnomeDock, I don't see any way of cleanly
avoiding those problems without depending on Gnome Libs 2.0, which we
don't want to do.  As far as things go now (thanks to Michael's
cleverness) we do have a workaround for the problems with GnomeApp.

 > 	d) Let components embed their toolbars via controls ( which would
 > contain a few of the standard GnomeToolbarItems BTW ).
 > 
 > 	Step d) solves the translation problem, the containee does its own
 > toolbar rendering and can put what it wants in there.

    We have gone down this road before!  I even wrote the code once,
and threw it away.  Please read over the archives of
gnome-components-list where this was discussed.

    Sure, it is easy to embed your toolbars via controls, and sure, it
does obviate large sections of the GnomeUIHandler code.  But it also
removes functionality; namely, embedded components will no longer have
the ability to embed toolbar items in pre-existing toolbars.  And the
reason that we decided not to go down that route was that we wanted to 
keep that functionality around.

    The issue can be brought up again, of course, and if we determine
that users don't care about this functionality, then by all means,
let's kill the existing code and put in the 200 lines or so which will 
implement the control-based toolbars.

    [ Of course, at that point, you have to realize that you've
actually created a general mechanism for components toembed arbitrary
widgets in a GnomeDock in the parent GnomeApp.  Which really has
nothing to do with toolbars specifically.  What do you want to call
this API? ]

 > 	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.

 > 	I can't believe the current method is the best. Furthermore the
 > code on which it relies appears not to have been designed with this sort
 > of abuse in mind.

    I don't think that this is nearly as serious as you say.  The
problems with the underlying code that I know of are:

        a. GnomeApp provides no way to get a handle to the GnomeDock
           which it creates when you add a docked item to the app.
           The workaround is  GNOME_DOCK_ITEM (GTK_WIDGET(toolbar)->parent).

        b. GtkToolbars do not reclaim freed space when toolbar items
           are removed from them.  There is no current workaround for
           this, sadly, and we will have to either fix GtkToolbar or
           use a new Toolbar widget.

And I can't honestly remember any others.

 > 	Also, I am rather appalled by the GnomeUIInfo structures that
 > float everywhere in the gnome-app stuff. 

    Yes, GnomeApp sucks.  Gnome-app-helper sucks.  Unfortunately, we
have to provide some kind of transitional layer for people to start
using the GnomeUIHandler, which is why the converters are there.

 > I can understand the need (
 > perhaps ) for structure initialization of menu trees for code
 > simplicity,

    In C perhaps.

Best,
Nat