On Mon, May 08, 2000 at 12:47:27AM +0200, Sven Neumann <neumanns@xxxxxxxxxxxxxxxxxx> wrote:
> The order of menus was determined by the order of installation. The code
> in plug-in.c uses readdir(). On most systems this will give you the plug-ins
> in the order the inodes were created.
I doubt it. But the usual order in directorirs comes close indeed.
This expalins why perl plug-ins were grouped together.
> more or less unpredictable, I have checked in some code today that orders
> the plug-ins and script-fu scripts alphabetically according to their
> translated menu-entries.
Very good!
> I have however noticed that perl i18n is totally broken at the moment (at
> least on my box) and I couldn't figure out why.
I checked in a patch yesterday (or the day before) that should fix the
".gmo files not created properly" problem.
> passed to menus_create_item...() correctly. Later I found out why this
> does not work: gimp-perl sets the domain-path to "/usr/share/locale".
> As the po build system in gimp-perl is definitely messed up since no
> gmo files are build ever, I can not determine if this is intentional.
I'll check (unfortunately, the drive with the sources just stopped
working, so I couldn't check it).
> I suggest that perl installs its message catalogs under the prefix
> however (which is /usr/local/ here) and uses gimp_plugin_domain_add()
> instead of gimp_plugin_domain_add_with_path().
Is it guarenteed that .mo files end up in "prefix"/share/locale/?
configure does not export the path that gettext uses (so rather than
trying to second-guess, I used the same prefix gimp-perl uses).
However, if gimp_plugin_domain_add_with_path works as advertised(?),
fixing the build process should suffice.
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@xxxxxxxxxxxxx |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
