Re: Tons of useless translations???
On Fri, Nov 26, 1999 at 01:03:08AM +0100, Sven Neumann wrote: > > In French I can say "Fichier->New" > > and then choose "Type d'image RVB, OK" > > Resulting image is called "SansTitre-0.0" > > > Well, if would be working correctly, it would say "Fichier/Nouveau...". ... but people are busily re-arranging all the furniture in the Gimp menu hierarchy, so "working correctly" will have to live with what it can for now. After my last compile I am now getting File->Nouveau, so hopefully tomorrow I can expect Fichier->Nouveau... at last. No Fichier->Fichier->Fichier here, if there was I would be figuring out why it was broken (even though I don't speak French) does someone who IS seeing this bug have the time to investigate it properly? Nick.
Re: Tons of useless translations???
On Fri, Nov 26, 1999 at 01:03:08AM +0100, Sven Neumann wrote: > And, yes I can reproduce this on a set of different machines. There's no > need to question Marc's statement... The only statement of Marc's that I'm questioning is the one where he blames Linux vendors for a problem that's only happening on SOME users of SOME combinations of Gimp version/ OS/ glibc/ whatever. I don't even think Marc is terribly serious about it, because he is venting a natural level of frustration with such an obnoxious yet difficult to track down bug. IMHO when it's finally traced we are NOT going to see an errata for SuSE, RedHat, Mandrake, Debian etc. but instead either a Gimp bug, or another "Please don't do stupid thing FOO" entry for a future Gimp developer FAQ I'm really NOT a god-like hacker, and I don't care much about i18n, yet it is working fine for me on an almost-fresh RH 6.1 install. So I just don't buy the "Linux vendors have conspired to screw up I18N" scenario, and I don't want to let them become a scapegoat. Those of you who are affected are MUCH better equipped to track down the bug than those of us who are unaffected (like Marc and myself). Nick.
Re: Tons of useless translations???
> For me at least, i686 based RH 6.1 on two machines (one more "out of box" > than the other, but neither of them's been extensively hacked) builds a > working and i18n'd Gimp no problem. > > In French I can say "Fichier->New" > and then choose "Type d'image RVB, OK" > Resulting image is called "SansTitre-0.0" > Well, if would be working correctly, it would say "Fichier/Nouveau...". And this is a bad example since most people seem to have problems with the translation of the plugins. So the question is does if you get the entry Fichier in lots of places where it shouldn't be. If you'd get it, you'd know what I speak of (Fichier->Fichier->Fichier). And, yes I can reproduce this on a set of different machines. There's no need to question Marc's statement... Salut, Sven
Re: CVS Gimp does not compile
At 22:18 25.11.99 +0100, Jarda Benkovsky wrote: >Hi, > >whenever I try to compile CVS Gimp, it crashes when compiling gdyntext >- undefined symbol gdk_font_list_free > gdk_font_list_free is the counterpart of gdk_font_list_new, which are - on X - wrappers to XListFonts / XFreeFontNames. gdk_font_list_* have a slightly different implementation on Win32. Maybe the exporting of gdk_font_list_free on X is not yet done. (I'm one of of the GimpWin hackers, but otherwise you should have similar problems with gdk_font_list_new) >I could find this symbol in win32 gtk files only, and since I do not >have windoze, ... However, there are other plugins besides gdyntext >which crash on similar things (gdk_root_parent). > As far as I've understood there is a general GDK reorganization in progress (started from Owen Taylor, not yet finished at least on Win32). IHMO the simpliest way to get a running Gimp again, would be to revert to the previous version of GDK/GTK (Pre 1.3.0). >Can somebody tell me what am I doing wrong? I have clean glib, gtk+ >and gimp checkouts, but it does not help :-( see above. The gtk+ checkout seems to be the problem, although not verified on Linux. Hans Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert
ANNOUNCE: GIMP 1.1.13
Brown paper bag release. Fixed that silly script-fu bug (thanks to yasuhiro for pointing that out) ftp://ftp.gimp.org/pub/gimp/unstable/v1.1.13/ Some i18n stuff went in too. -Yosh
CVS Gimp does not compile
Jarda Benkovsky writes: > whenever I try to compile CVS Gimp, it crashes when compiling gdyntext > - undefined symbol gdk_font_list_free You shouldn't be using the HEAD branch of GTk+ on Unix/X11. Especially not now when its in the middle of massive changes. (It used to be for a long time that the X11 parts of HEAD GTk+ wasn't being touched, but now that has changed.) Use GTk+ 1.2 (the gtk-1-2 branch in CVS). --tml
CVS Gimp does not compile
Hi, whenever I try to compile CVS Gimp, it crashes when compiling gdyntext - undefined symbol gdk_font_list_free I could find this symbol in win32 gtk files only, and since I do not have windoze, ... However, there are other plugins besides gdyntext which crash on similar things (gdk_root_parent). Can somebody tell me what am I doing wrong? I have clean glib, gtk+ and gimp checkouts, but it does not help :-( Edheldil
Re: Tons of useless translations???
On Wed, Nov 24, 1999 at 06:10:29PM -0500, Federico Mena Quintero <[EMAIL PROTECTED]>
wrote:
> Please note that "LANG=de" will not work
Really? It works fine on all my systems (and also some non-linux systems)
;) It does not work, though, on the redhat systems I recently saw.
> Please read the libc
>From the libc documentation:
"Later we will describe how to construct locales XXX."
Hmm, no help there.
> and gettext documentation for information about
>From the gettext documentation:
"For example, let's presume a German site. At the shell prompt, users
merely have to execute `setenv LANG de' (in `csh') or `export LANG;
LANG=de' (in `sh')."
(I should have read that part of the info docs long ago, since it also
describes LINGUAS one page earlier!)
These kind of examples are scattered throughout the gettext documentation,
e.g.:
/* Change language. */
setenv ("LANGUAGE", "fr", 1);
I have not found a formal description of what goes into LANG, though,
there.
So LANG=de is in full accordance with the gettext and libc documentation
(and unix documentation as well) AND actual reality.
> [LINGUAS is used to specify which languages you care about when
> installing translations; a French person may not want to have to
> install Chinese translations.]
Thanks for the explanation! This sounds highly useful ;)
I18N seems so highly complicated that everybody disagrees on how it works
on not :(
--
-==- |
==-- _ |
---==---(_)__ __ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
Re: How to make scripts undoable?
On Thu, Nov 25, 1999 at 04:32:27PM +0100, Raphael Quinet <[EMAIL PROTECTED]> wrote: > familiar with this code could help me a bit or add some documentation > to the undo code, then I will attempt to fix gimp_undo_push_group_start. I can understand this, but how about just _replacing_ these two pdb functions by functions that do the equivalent of what you are doing? > feature freeze into account. I delcare these are bug-fixes ;) > everything in the current image, and so on. I prefer to let each > script do exactly what it wants to do, instead of copying the whole > image every time. There are serious drawbacks to this way of doing it that IMHO outweight the memory-savings: - third-party-scripts will not profit form this. - only you will understand how it's done - it requires a relatively complicated source change (rather than just a renamed function). > On the other hand, wrapping this into two PDB calls would indeed look > much cleaner (even if the internals are still ugly) and it would be > easier to implement this in a better way later. Would it be possible to mimic the semantics of the undo_group-functions? Maybe these could just be replaced (perfect). But I would really prefer two pdb calls, if that is possible (maybe similar to the export functionality). > So... errr... I don't know what to do. Does anybody have strong > preferences very strong ;) how large is the speed/memory penalty? > Or a third one (fixing gimp_undo_push_group_start)? I think doing this "right" before 1.2 is faaar to complicated. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: using dpi more than 72
Thanks, but I think this is where I drop out, don't know about this. but if you can give me a link to a read me (or where I am suppose to read it) then I will give it a bash, and also, is this scm2scm included with the source of Gimp, or must I get it separately? What else could I have missed to get my script's not to work? Thanks again Marc Lehmann wrote: > On Wed, Nov 24, 1999 at 11:21:29AM +0200, Koot <[EMAIL PROTECTED]> wrote: > > now my "script-fu" is not working (most of them), will have to go and figure what >is > > needed to get it to work again. > > There is a perl script named scm2scm that can, in theory, read in a > script-fu and write it out again, updated for the version 1.2 api. I.e. > try something like this on a BACKUP of your scripts: > > scm2scm -t 1.2 *.scm > > The problem is that it was not updated since a few months, so many changes > are not yet reflected. > > However, if you find it useful and tell me whats missing I'd be happy to > update it for 1.2. > > -- > -==- | > ==-- _ | > ---==---(_)__ __ __ Marc Lehmann +-- > --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| > -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ > The choice of a GNU generation | > |
Re: Tons of useless translations???
On Thu, Nov 25, 1999 at 03:32:40PM +0100, Marc Lehmann wrote: > I just declare all linux distributions (exc. DIY) as broken, as i18n works > perfect on my machine. Not to be contrary Marc, but it is not the fault of the vendor if a user or admin screws up their machine some how. No-one except SuSE (spit) are shipping Gimp 1.1.x in the box, so it's likely that if it doesn't work the user screwed up, not the vendor. For me at least, i686 based RH 6.1 on two machines (one more "out of box" than the other, but neither of them's been extensively hacked) builds a working and i18n'd Gimp no problem. In French I can say "Fichier->New" and then choose "Type d'image RVB, OK" Resulting image is called "SansTitre-0.0" Is there something more I should play with to check that i18n works? I can't really ask my other test users to play with this, it's a bit much already that they are running 1.1.x and must suffer the roller-coaster ride to help me find bugs :) I understand Marc's frustration that this bug refuses to be tracked down but will blaming all Linux vendors collectively help? Nick. PGP signature
Re: Tons of useless translations???
On Thu, Nov 25, 1999 at 10:35:29AM +0100, Michael Natterer <[EMAIL PROTECTED]> wrote: > > Marc, to add an entry to your which-distribution-is-the-evil-one: > I use Suse 6.1, gettext 0.10.35 and glib, gtk and gimp from cvs (of course ;-) Ok, I give up the hunt. Obviously: - the version of gettext is of no concern - the distribution is of no concern - gtk+ is probably not the culript: different versions show the bug - same for glib - the configure flags are of no concern I just declare all linux distributions (exc. DIY) as broken, as i18n works perfect on my machine. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Tons of useless translations???
> (btw, can anybody tell me why redhat ignores LANG? and what is this > LINGUAS thing anyway? maybe because other variables like LC_ALL are also > set and take precedence?) Please note that "LANG=de" will not work. You are missing the country specifier; you need "LANG=de_DE" for Germany. Likewise, you would use "es_MX" for Spanish in Mexico or "es_ES" for Spain. Please read the libc and gettext documentation for information about this. [LINGUAS is used to specify which languages you care about when installing translations; a French person may not want to have to install Chinese translations.] Federico
Re: How to make scripts undoable?
On Thu, Nov 25, 1999 at 04:32:27PM +0100, Raphael Quinet wrote: > So... errr... I don't know what to do. Does anybody have strong > preferences for one solution (several calls in each script) or the > other (two PDB calls hiding the gory details)? Or a third one (fixing > gimp_undo_push_group_start)? Can I clear up (off list if this is already well known) what Raph wants gimp_undo_push_group_* to do, versus what they do now? My instinct is that this IS a bug fix (regardless of whether it might break some other things) and has a good stab at being in 1.2.x, but I ought to know what I'm letting myself in for... Nick. PGP signature
Re: How to make scripts undoable?
On Wed, 24 Nov 1999, Marc Lehmann <[EMAIL PROTECTED]> wrote: > On Wed, Nov 24, 1999 at 12:13:56AM +0100, Raphael Quinet <[EMAIL PROTECTED]> wrote: > > How to make these scripts undo-aware? The problem is not really > > I'd say the obvious way would be to make gimp_undo_push_group_start just > "work", rather than adding another kludge no user will ever understand. I agree, that would be the right way to do it. However, after looking for a while at undo.c, undo_cmds.c and related files, I thought that I'd better refrain from fixing the undo groups because I might break too many things while trying to fix that. If a developer who is more familiar with this code could help me a bit or add some documentation to the undo code, then I will attempt to fix gimp_undo_push_group_start. > If you must, name it something different, but adding multiple lines to a > plug-in *just* to make it work together with other plug-ins seems a large > step backwards. I agree that it is not an elegant solution (I said so in my message) but at least this is a solution that would work for 1.2, taking the feature freeze into account. I can re-modify the scripts later, when a better undo system is included in version 1.3. If necessary, these "undo kludges" in the scripts can be marked with a comment saying that future versions of the GIMP will use a nicer solution. > I mean, the semantics of bracketing scripts with these calls is obvious, and > does not include "is very slow". This is an implementation detail that should > be optimized away. > > If your solution can be implemented as two pdb calls (start and stop) then > this would be fine. I thought about this for a while, but I prefered to put the code directly in the scripts because several scripts will use this method in slightly different ways: some of them will only modify one layer, some others will modify/add several layers, some others will modify everything in the current image, and so on. I prefer to let each script do exactly what it wants to do, instead of copying the whole image every time. On the other hand, wrapping this into two PDB calls would indeed look much cleaner (even if the internals are still ugly) and it would be easier to implement this in a better way later. So... errr... I don't know what to do. Does anybody have strong preferences for one solution (several calls in each script) or the other (two PDB calls hiding the gory details)? Or a third one (fixing gimp_undo_push_group_start)? -Raphael
Re: Some menu stuff..
On Thu, Nov 25, 1999 at 02:17:22AM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > No, they can't (yet). ;-> > > OTOH, it would be trivial to re-implement this in C (for 1.2). > > This has been on my TODO list for oh so long. Expect this feature to > appear in CVS soon... I see now that I was ambiguous... I meant it would be trivial to re-implement the perl-oneliner as a "goody" for 1.2. I didn't want to say that it would be trivial to add plug-ins to the L&C menu. If you think otherwise, though, this is fine ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Tons of useless translations???
Sven Neumann wrote: > > > >The string gets passed through menu_translate when the labels are build, so > > >it should work for all menus. Hmm, I have now changed this. > > > > A problem is that there is no table for "/Filters/Blur/tearoff1" > > or "/Filters/Blur" in gimp.pot or gimp-std-plgins.pot. The menu > > translating function in gtk uses only a last item of menu path... > > > > I'd vote for creating such menusentries in the core. Not only to solve this > problem (that can eventually be solved another way), but so that we can put > the Filter menus into a nice order with seperators etc. Right. I will checkin a patch today which defines all submenus under /Filters. And I've removed all predefined tearoff entries and defined the menu branches instead. This gives us proper translation for the submenus. (The tearoffs are built on the fly then). However, I still didn't find out why my installation is unable to lookup translations from "gimp-std-plugins". Marc, to add an entry to your which-distribution-is-the-evil-one: I use Suse 6.1, gettext 0.10.35 and glib, gtk and gimp from cvs (of course ;-) bye, --Mitch
Re: i18n of menupaths - perl
Marc Lehmann wrote: > > How do I get the perl menupaths into the gimp .po file? it is no problem > to mark them, but the standard xgettext program is not able to parse perl > source. Well, I don't know how to solve this... > Should these go into the gimp-std-plugins-file? Should I put all > translations into that file then? ...but I'd vote to put the gimp + plugin + perl + whatever-is-in-cvs-gimp into _one_ catalog. What do you think? Getting translations from the std. "gimp" textdomain doesn't seem to be a problem for anybody, so this would also solve the problems with different distributions. bye, --Mitch
