Hi,
> I'd recommend gimp_plugin_domain_add (gchar *domain_name)
> and gimp_plugin_domain_add_with_path (gchar *domain_name,
> gchar *domain_path)
>
> because it IMHO fits better into the namespace and is more obvious
> than to have just 1 function with two meanings.
Ok, I'll change it then and provide two wrappers for one PDB call.
> I sent a newer patch in my last mail. It should do everything we need
> for now.
No, it will most likely crash the Gimp (explanation of the usage
of GSList in a private mail) and it won't work the first time the
plug_in is started.
> I totally agree with this solution, so let's finalize it and get it
> into the tree.
I'll check my code in in a few minutes. Should provide a framework
to add the rest upon.
> > While working on the code I came across a new idea which would
> > simplify things quite a bit eventually: The plugins create their
> > menu_entry in app/plug_in.c in the function plug_in_make_menu (). Why
> > not use the knowledge about the domain_name the translated string is
> > to be found in and only look it up in that domain by passing it to
> > menus_create_item_() ? You'd only have to change the code to iterate
> > through the plug_in_defs instead of proc_defs since the domain is
> > stored with the plug_in definition.
>
> I'm afraid I don't understand that. Could you please explain it again?
Ok, I'll try: Right now we will have to iterate through all domains
when trying to translate the menus. Since we know what domain the plugin
is in, we are able to choose the right one when its procedures try to
install the menupath. Since that is done from plug_in.c it would be
possible to pass the domain to the menu_item_factory code. Of course
we will still have to bind to all domains in our list.
Salut, Sven
PS: BTW, I did not ment you and Marc in my comment about the print plugin.
Why do you think so? But I might be at least partly guilty ...
