Re: Testing and integration of The i18n solution(TM)
Hi,
I'd suggest testing for existance of the parent menu first and
if it's not there extracting the correct translation for it from
the full path and initialize it together with the tearoff menu.
On the first thought the idea looks promising, but I fear it is
not that easy. GTK+ wants to create the menu using the orginal
strings. The translation is only used when the label is to be
displayed.
Therefore it then calls our menu_translate functions which takes
care of appending the factory name (Image, Toolbox, ...) to
the string, passing this string to gettext and removing the factory
name from the translated result. GTK+ takes the returned string
and strips away everything up to the last '/' and puts that into
the menu_label. At least that is my impression of how it works.
Submenus are created on the fly when they are needed. Unfortunately
they have to be created before the actual menu_entry can be added.
That means if
Image/Filters/Render/Nature/Flame...
is to be created, the submenu
Image/Filters/Render/Nature
is created automatically. Unfortunately there is no such string
in the textdomain of the plugin and the lookup fails. If the lookup
order would be different, it would be easy to store the result of the
latest lookup and strip the last part. But that's fiction :-(
I have an idea how it could work, but I think the overhead is
not worth the issue: Before we build the menus, we could create a
hashtable containing translations of all menu_entries including
the menu_paths (that can be easily generated by recursively
truncating the translations after the last '/' and use that
hashtable later instead of calling gettext again.
Better ideas anyone?? If not, I'd say we move the dummy_entries
into the plugins. Whoever is interested in doing this (sorry,
I won't), insert the following line into menus.c to get a list
of the affected menus:
app/menus.c (line 979) g_print ("%s\n", entry-entry.path);
Salut, Sven
Re: Coding style (was: PROPOSAL: New i18n solution)
:set cinoptions={0.5s,^-2,e-2,n-2,p2s,(0
Works most of the case.. (maybe not perfect, but..)
Thanks a lot! I just put it in the programming guidelines.
Federico
LIST OF 1,429 ITEMS DUE FOR QUANTITATIVE RESTRICTIONS REMOVAL BY GOVERNMENT OF INDIA
Know latest developments relating to exports and imports and surprise your competitors. We also offer business links with leading manufacturers,exporters and importers from SAARC countries and around the World. The SAARC countries consist of India,Pakistan,Sri Lanka,Bangladesh,Nepal, Bhutan and Maldives. Please visit our website http://www.saarcyellowpages.com and Register by clicking on "New Companies Register Here".
Re: Crash in Gimp 1.1.7 on Solaris 8.
On 23 Feb, Ludovic Poitou wrote:
SunOS bondi 5.8 Generic sun4u sparc SUNW,Ultra-5_10
UltraSPARC-IIi
But I haven't compiled with the 64 bit flag on !
A simple program like this :
main(){
printf("%d\n", sizeof(unsigned char *));
}
Do the plugins work for you? We've got dozens of problems with
GIMP on 64bit architectures not using gcc for compilation.
--
Servus,
Daniel
Re: Magicless file formats
Targa files have no magic header, and cannot be reliably identified that way. [snip] "New" Targa files have a magic string at the end of the file[1], plus a bunch of extra information. The Targa specification tells you how and where to expect it. It does says that for old files you are basically screwed :-( Federico [1] Yes, this is broken.
Re: Magicless file formats
"New" Targa files have a magic string at the end of the file[1], plus a bunch of extra information. The Targa specification tells you how and where to expect it. It does says that for old files you are basically screwed :-( I know that, but since a) the Gimp magic pattern language doesn't seem to allow matching a string at the end of a file, and b) many (most!) TGA files today follow the old specification, it is of no help. Anyway, if the user finds that an application doesn't try to load a file whose name ends in .tga as a Targa file (or worse, attempts to load it as a Group 3 fax file), then the same user will assume that the application, or its programmers, or both, are stupid beyond belief. And rightly so :-) (Was it OK to post a patch to this list, or should I have sent it somewhere else? To some CVS repository? Please forgive my cluelessness.)
Re: Gimp batch mode
Hi, I am trying to get batch mode working with script-fu-old-photo. However I cannot get it working despite my attempts to follow the docs on adrian.gimp.org. Does anyone have any suggestions on how I can get this working or of another program which will allow me to do this. I need to edit ~500 images and it would save me a lot of time if i can get it done automatically. Don't know if and why batch-mode is broken, but there is a plug-in on the registry called glob wich comes in very handy. You don't need to use the batch-mode with it, since it allows you to use shell globs like "*.jpg" in a script-fu. Just write a small wrapper script in script-fu that calls script-fu-old-photo for each file in the list returned from the file-glob command. Perhaps we should add that plugin to the distribution? Since it does not even create a menuentry and is pretty short, it wouldn't hurt us much... Salut, Sven
Testing and integration of The i18n solution(TM)
Hi,
the new i18n implementation supports localisation of
plugins outside the gimp distribution. I'm pretty sure
that it works. I have however not yet tested if it
really does what we expect and if it solves the problems
it targets. Is there anyone out there maintaining a
seperate plugin who is interested in internationalising
it? It would be very nice to get some feedback if the
current solution works under realistic circumstances.
One thing definitely needs to be done before the new
framework is really usable: gimptool should provide the
LOCALEDIR definition (together with the cflags?) so
plug-ins that want to put their compiled message
catalogs at the same place where the default gimp catalogs
are located, can easily bind their textdomain using:
bindtextdomain ("gimp-plugin-foobar", LOCALEDIR);
and notify the gimp about its textdomain by calling:
gimp_plugin_domain_add ("gimp-plugin-foobar");
Would be nice if someone else could take care of changing
gimptool and doing a little testing...
If you need more explanations how the new system is
supposed to work, let me know. Anyway I'll try to add a
few lines to README.i18n in the next days.
Salut, Sven
"The i18n solution"(TM) is a registered trademark owned by Daniel Egger
Re: Testing and integration of The i18n solution(TM)
Hi, SHIRASAKI Yasuhiro [EMAIL PROTECTED] noticed: some paths like: Image/Video Image/Script-Fu/* are not translated with "The i18n solution"(TM). Shell we move dummy_entries[] items from app/menus.c to each appropriate plug-ins? Eek, yes of course, that does not work any more. There are two ways to solve this: Either we search in the gimp domain if the lookup of the menupath failed (like we used to do (*)) or we move the dummies into the plugins. I prefer the latter, since it is the cleaner solution. There are a few entries in menus.c that should already be included in the perl domain, since Marc moved his stuff out into the Perl-Scripts. Obviously each plug-in that wants to add an extra menu that is not build by the Gimp core has to provide its own dummy-entry for it. We could of course build all the menus we need for the default plugins, but that would result in empty menus if stuff is uninstalled. Salut, Sven (*) The new solution has the advantage that we could look up the translation in the plugins domain first where we will most likely find a translation and only fall back to the core if not. Before we always used the gimp domain first.
Re: Testing and integration of The i18n solution(TM)
On 24 Feb, Sven Neumann wrote: the new i18n implementation supports localisation of plugins outside the gimp distribution. I'm pretty sure that it works. I have however not yet tested if it really does what we expect and if it solves the problems it targets. Is there anyone out there maintaining a seperate plugin who is interested in internationalising it? It would be very nice to get some feedback if the current solution works under realistic circumstances. I'll test a few plugins soon. Would be nice if someone else could take care of changing gimptool and doing a little testing... I'll look into that, too. If you need more explanations how the new system is supposed to work, let me know. Anyway I'll try to add a few lines to README.i18n in the next days. But don't correct my typoes... :) "The i18n solution"(TM) is a registered trademark owned by Daniel Egger Hey Sven, come on... -- Servus, Daniel
Re: Menus in Toolbox
Hi, Would it make sense to you to enable keyboard access to the menuentries in the toolbox? I find it quite irritating that I can't get the File dialog with Alt-F resp. Alt-D (German Datei). At least for beginners not yet familiar with the shortcuts or the do-it-yourself- shortcut-system it would be a good start to use GIMP like any other program. Also this would allow to reach the entries from the Xtns menu better. Very good idea, indead! Patch already applied. Looks funny to see where gtk+ builds the Help menu if you use Alt-H on a 1-column toolbox layout. Salut, Sven
Re: Testing and integration of The i18n solution(TM)
On 24 Feb, Sven Neumann wrote: Eek, yes of course, that does not work any more. There are two ways to solve this: Either we search in the gimp domain if the lookup of the menupath failed (like we used to do (*)) or we move the dummies into the plugins. I prefer the latter, since it is the cleaner solution. I'd suggest testing for existance of the parent menu first and if it's not there extracting the correct translation for it from the full path and initialize it together with the tearoff menu. -- Servus, Daniel
AW: AW: Crash in Gimp 1.1.7 on Solaris 8.
-Ursprüngliche Nachricht-Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]Im Auftrag von Ludovic
PoitouGesendet: Donnerstag, 24. Februar 2000 14:13An:
Daniel H.Betreff: Re: AW: Crash in Gimp 1.1.7 on Solaris
8.Hey man,
Relax,
You are registered on a public mailing list :
[EMAIL PROTECTED] If you don't want to receive mails from
this mailing list, unsubscribe. Otherwise, you will keep on receiving
emails. If you're too dumb to figure this out, unplug your PC and you'll
never get any further mails !
Ludovic.
"Daniel H." wrote:
don't wirte me Again!! I've never mailes
you It was a joke from a other persondon't wirte me
Again!! I've never mailes you It was a joke from a other
persondon't wirte me Again!! I've never mailes you It
was a joke from a other persondon't wirte me Again!! I've
never mailes you It was a joke from a other persondon't wirte me
Again!! I've never mailes you It was a joke from a other
person
-Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Im
Auftrag von Ludovic Poitou Gesendet: Mittwoch, 23. Februar 2000
19:35 An: Tim Mooney Cc: Ludovic Poitou;
[EMAIL PROTECTED] Betreff: Re: Crash in Gimp 1.1.7 on
Solaris 8.
Tim Mooney wrote:
In regard to: Crash in Gimp 1.1.7 on Solaris 8., Ludovic Poitou said
(at...: signal BUS (invalid address alignment) in
color_pixels at 0x177858
color_pixels+0x110:
ld [%l0], %i1 You don't say
what architecture you're running on, but Solaris 7 or later on
an Ultra would be a LP64 (i.e. 64 bit) OS, so an invalid address alignment
would be indicative of incorrect alignment of a pointer. I'm
not certain, but odds are good that pointers in Solaris 8 must be
aligned on 8-byte boundaries, as opposed to ints which could be
aligned on 4-byte boundaries.
SunOS bondi 5.8 Generic sun4u sparc SUNW,Ultra-5_10 UltraSPARC-IIi
But I haven't compiled with the 64 bit flag on !
A simple program like this : main(){
printf("%d\n", sizeof(unsigned char *)); }
returns 4 !
Ludovic.
register unsigned char c0, c1, c2;
register guint32 *longd, longc; register
guint16 *shortd, shortc; I can't tell by the code what the
intent is, but these definitions have longd as a pointer (an 8-byte
quantity on LP64 machines) while longc is an unsigned 32-bit
quantity (*not* a pointer). Ditto for shortd and shortc.
switch (bytes) {
case 1: memset(dest,
*color, w); break;
case 2: shortc =
((guint16 *)color)[0]; This is probably also a problem
here -- shortc isn't big enough to hold an address.
shortd = (guint16 *)dest;
while (w--)
{
*shortd = shortc;
shortd++;
} break;
case 3: c0 =
color[0]; c1 = color[1];
c2 = color[2];
while (w--)
{
dest[0] = c0;
dest[1] = c1;
dest[2] = c2;
dest += 3;
} break;
case 4:
longc = ((guint32 *)color)[0]; Crash here !
longc is a 32 bit quantity, which isn't big enough to hold
an address on LP64 machines. That's probably why you're
getting the crash. I bet I would get the same result (or at
least an "unaligned access" warning) on my Tru64 Unix box.
longd = (guint32 *)dest;
while (w--)
{
*longd = longc;
longd++;
} break;
default: {
int b;
while (w--) {
for (b = 0; b bytes; b++)
dest[b] =
color[b];
dest += bytes; }
} } }
I'm not sure what the right fix is, being I haven't looked long enough at
the code to decipher what's going on. The problem is almost
certainly a 32 bit vs. 64 bit issue, though.
Tim -- Tim
Mooney
[EMAIL PROTECTED] Information Technology
Services (701) 231-1076
(Voice) Room 242-J1, IACC
Building
(701) 231-8541 (Fax) North Dakota State University, Fargo, ND
58105-5164--
Ludovic Poitou
Sun Microsystems Inc.
iPlanet E-Commerce Solutions - Directory Group - Grenoble - France
