Bug with make uninstall
Hello, I found a bug with "make uninstall" in version 1.2.0 (this bug is present in earlyer versions, too). I have no Parse::RecDescent and therefore scm2perl will not work and not be installed. When uninstalling, make tries to unlink scm2perl unlink /usr/bin/scm2perl Cannot forceunlink /usr/bin/scm2perl: No such file or directory at -e line 1 and stops make: *** [uninstall-recursive] Error 1 WORKAROUND: make -k uninstall since it has to be fixed in the perl makefile and I am no perl user :-( I leave this for the experts. Uwe -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
Bug in configure
Hello, "./configure --help" gives a wrong default for "--enable-gimpdir": --enable-gimpdir=DIRchange default gimpdir from .gimp to DIR must be .gimp-1.2 Same change in INSTALL. (I don't know wether I can use variables, so I can't make a patch) maybe it would be a good idea, to explain that gimpdir is the personal dir and does not affect the global dirnames. Uwe -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
Re: [Uwe Koloska] Menus/shortcuts/etc
Marc wrote on Mittwoch, 13. Dezember 2000 21:21: On Wed, Dec 13, 2000 at 04:36:16PM +0100, Tino Schwarze [EMAIL PROTECTED] wrote: There is _no_ Unix way. Yes, there is: Look at Netscape's shortcuts, e.g. "Close Window". They are all configurable ;) I, for example, press alt-f4 (window-manager) or "esc" (netscape configuration). The unix way was and is: Let the user choose. Yeah, that's exactly what I intend to say. I don't speak about unix' standard way but th unix way. And this way has one other rule: Make it simple! Uwe -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
freetype plugin
Hello, since the new beta of freetype plugin was announced on http://www.xach.com/gimp/news/index.html I tried to reach its homepage at http://freetype.gimp.org but never got any response from the server with an error: Cannot open the HTTP connection to freetype.gimp.org port 80; [No route to host]. Anyone with the same problem or a better address? Uwe -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
bug in patch-1.1.27-1.1.28
Hello, to save some download time ;-) I tried to upgrade from 1.1.27 to 1.1.28 with the patch file. I found some minor problems; some files are incorporated in their final form and not in the ini-form: gimp-remote.1 gimp.1 gimp.spec gimprc.5 gimptool.1 libgimp/gimpfeatures.h have to be: gimp-remote.1.in gimp.1.in gimp.spec.in gimprc.5.in gimptool.1.in libgimp/gimpfeatures.h.in Yours Uwe -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
Re: api break before release
You wrote on Fre, 25 Aug 2000: Date: Fri, 25 Aug 2000 01:08:42 +0200 From: Sven Neumann [EMAIL PROTECTED] [blurb about #ifdef GIMP_ENABLE_COMPAT_CRUFT] Are you sure? Why does it work for the gimp-print plug-in then? We've been using the old names. I ran Sven's conversion script to generate the new names, and put a whole stack of #define's in the one UI-related file that's shared between the 1.0 code and the 1.2 code. What about a common header that makes this defines? So a plug-in maintainer can use the new conventions and if the plug-in should be compiled for the old api, this can easily observed by including this header. (Don't know exactly about the under-the-hood complexity of what I'm talking about ;-)) Uwe -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
color selector with cmyk anyone?
Hello, I finally found some books about color harmony (that's exactly the title of the series -- brandnew in europe, but originally from 1997). But all the colors are given as DIC numbers or CMYK. So my questions: o Is there an easy to use tool for selecting colors as CMYK and give the RGB? Yes, CMYK gamut != RGB gamut. I am only looking for a starting point so that I don't have to startup photoshop for looking what RGB I have to choose ... o is there a DIC palette / color chooser for gimp? For the long run I wanna try to make something like a matching color browser. Yours Uwe Koloska -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
BUG: tearoff menu of closed window can't be closed
Hello, with 1.1.22 I have discovered the following problem: - (only one image open) - tearof an imagemenu (say filter) - close the image - try to close the menu with the triangle at the upper left - open another image - close the tearof same with more than one image open, but then you can change the active image and are able to close the tearof. yours Uwe Koloska -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
gimp-1.1.21: Problem with perl/po
Hello, I just tried to install gimp-1.1.21 -- an succeded! Many thanks to all! But there was a problem during "make install". In plug-ins/perl/po it says: cp cs.gmo /opt/Gnome/share/locale/cs/LC_MESSAGES/gimp-perl.mo cp: cs.gmo: No such file or directory make: [install-po] Error 1 (ignored) the same for all the other languages: de.gmo, fr.gmo,it.gmo, no.gmo, ru.gmo By examining the problem I found that there are no *.gmo-files only the *.po. Is there a step missing that transforms the *.po into *.gmo? And yes, I have gettext-0.10.35 and am working under linux-2.2.14, glibc-2.1.2, gcc-2.95.2. And no, I don't know wether this problem appeared in 1.1.20 or before because normally I went away while gimp compiles and installs. Only this time I have been in front of my screen just in time when the make-errors occured. I have tried some perl-plugins and they work, but some have only the english texts (don't know wether this is caused by the error or by lacking any translation) BTW: Who ist responsible for the tips and their translations? Or the translations for all the gimp? Does a document exists, that describes the common terms for some languages? Like: layers Ebenen ... colours Farben ... Yours Uwe Koloska -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
Re: gimp-1.1.21: Problem with perl/po
You wrote on Don, 04 Mai 2000:
On 4 May, Uwe Koloska wrote:
But there was a problem during "make install". In plug-ins/perl/po it
says:
cp cs.gmo /opt/Gnome/share/locale/cs/LC_MESSAGES/gimp-perl.mo
cp: cs.gmo: No such file or directory
make: [install-po] Error 1 (ignored)
the same for all the other languages: de.gmo, fr.gmo,it.gmo, no.gmo,
ru.gmo By examining the problem I found that there are no *.gmo-files
only the *.po. Is there a step missing that transforms the *.po into
*.gmo?
Seems so. Seems like the .gmo files were not generated and you have the
necessary gettext tools not installed.
I have installed gettext from source (my distribution is from '95 ;-))
all is there especially msgfmt:
checking for LC_MESSAGES... (cached) yes
checking whether NLS is requested... yes
checking whether included gettext is requested... no
checking for libintl.h... (cached) yes
checking for gettext in libc... (cached) yes
checking for msgfmt... (cached) /usr/local/bin/msgfmt
checking for dcgettext... (cached) yes
checking for gmsgfmt... (cached) /usr/local/bin/msgfmt
checking for xgettext... (cached) /usr/local/bin/xgettext
in plug-ins/perl/po/Makefile{.PL} there is a rule for "%.gmo: %.po" and a
target "update-gmo" but it seems that the latter wasn't called ...
a manual "make update-gmo" in plug-ins/perl/po works just fine and produces
all the missing *.gmo-files
BTW: Who ist responsible for the tips and their translations?
Every one who wants to, send a patch and it will be surely applied
by someone, most probably Sven. :)
I will look into it.
german
eine Übersetzung hat mich bei den Tips aber besonders gestört (vielleicht
auch noch woanders?) "Selection" != "Selektion", viel besser ist "Auswahl"!
Vielleicht schaffe ich es in den nächsten Tagen mal einen Patch zu schreiben
/german
Or the translations for all the gimp?
The are in big parts Svens and my fault... :)
Does a document exists, that describes
the common terms for some languages?
Like: layers Ebenen ...
colours Farben ...
I suggest (and maybe volunteer) for a list of technical terms with their
proper translations. On the first hand this will ease posting to this
newsgroup without restarting gimp with LC_ALL=C ;-))
Yours
Uwe Koloska
--
mailto:[EMAIL PROTECTED]
http://rcswww.urz.tu-dresden.de/~koloska/
----
right now the web page is in german only
but this will change as time goes by ;-)
Re: BUG: gdyntext is dead
You wrote on Die, 18 Apr 2000: Hi, Where are you experts??? We are two at minimum discovering this behaviour and if it's a misconfiguration it has to be described somewhere. It is a misconfiguration on your part. I'm running gimp 1.1.19 from debian and GDynText appears to be working fine. I typed text and it appeared in a new layer. I'm afraid Uwe's original report is correct. GDynText is totally broken when used under any locale, because it seems to do bad thing to the X font spec's "encoding" field. I'm thinking about hacking it but I don't promise anything :) Hey, you are right! By starting gimp with LC_ALL=C gimp-1.1 or more exact LC_NUMERIC=C gimp-1.1 gdyntext works as expected. Maybe this is the same sort of error acrobat reader 4.05 has to fight with (cannot open most embedded font when run with locale other than "C"). No, this problem is definitely configuration-specific. I have no problems with GDynText on this debian (potato) system running gimp under whatever locale I like. But what's wrong with my configuration? The locales are straight from glibc-2.1.2. localedef -i de_DE -f ISO-8859-1 de The definition of LC_NUMERIC: decimal_point "comma" thousands_sep "period" grouping 3;0 Good news if this is no gimp bug, but it falls on gimp if gimp isn't able to work with this special (mis)configuration. I will go into it -- and I am glad to hear from you ;-) I have done some tests with gimp-1.1.19 and gdyntext-1.4.4 (-DDEBUG) LANG=de gimp-1.1 --- Loading font: -*-agate-bold-r-normal-*-50-*-*-*-*-*-*-* [...] GDT: space width = 2 GDT: 16x 5 A: 4 D: 1 [Test] GDT: MH:5 LH:4 --- LC_NUMERIC=C gimp-1.1 --- Loading font: -*-agate-bold-r-normal-*-50-*-*-*-*-*-*-* [...] GDT: space width = 18 GDT: 87x 50 A: 38 D: 12 [test] GDT: MH:50 LH:32 --- Then I tried to give the same command that gdyntext uses in the script-fu console with LANG=de: (gimp-text-get-extents "A A" 50 PIXELS "*" "agate" "bold" "r" "normal" "*" "*" "*") (100 50 38 12) (gimp-text-get-extents "AA" 50 PIXELS "*" "agate" "bold" "r" "normal" "*" "*" "*") (82 50 38 12) As you can see the result is correct (100 - 82 = 18) Debugging with ddd (gdb-4.18) shows that all parameter are correct. Where in gdyntext.c or in gimp_run_procedure() is a function that uses the LC_NUMERIC locale setting -- that is not used by scrip-fu??? Uwe -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
Re: BUG: gdyntext is dead
I wrote on Mon, 10 Apr 2000: Hello, since 1.1.17 (maybe before and maybe the gimp version is unrelated to the problem) the gdyntext-plugin produces no result. Oh it produces a new but just too small layer with the necessary parasites -- but the text isn't visible. I have tested: o gimp-1.0.4 with gdyntext-1.4.1 that goes well in the past so this looks like some changes in the environment o gimp-1.1.1[789] with the packaged gdyntext and the actual gdyntext 1.4.4 dircet from the authors website o disable the ttf-fontserver (xfsft-1.1.6) xset -fp tcp/localhost:7100 xset fp rehash o running gdyntext with "-DDEBUG" enabled gives GDT: space width = 2 GDT: 34x 5 A: 4 D: 1 [Hallo Welt!] GDT: MH:5 LH:4 My system: linux-2.2.1[14] xfree86-3.3.5 glibc-2.1.2 gcc-2.95.[12] xfsft-1.1.6 only for ttf -- x-fonts and typ1 through the X-Server gtk+-1.2.7 The (script-fu gimp_text_get_extends ...) given on the console shows a resonable behaviour. Where are you experts??? We are two at minimum discovering this behaviour and if it's a misconfiguration it has to be described somewhere. Because there was a suggestion that xfree86-3.3.5 can be the reason, I upgraded to 3.3.6 but nothing changes. The new text layer is a small rectangle in the upper left corner ... For testing I have also removed my ~/.gimp-1.1 (nice startup wizard!) but no effect ... Yours Uwe Koloska -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
BUG: gdyntext is dead
Hello, since 1.1.17 (maybe before and maybe the gimp version is unrelated to the problem) the gdyntext-plugin produces no result. Oh it produces a new but just too small layer with the necessary parasites -- but the text isn't visible. I have tested: o gimp-1.0.4 with gdyntext-1.4.1 that goes well in the past so this looks like some changes in the environment o gimp-1.1.1[789] with the packaged gdyntext and the actual gdyntext 1.4.4 dircet from the authors website o disable the ttf-fontserver (xfsft-1.1.6) xset -fp tcp/localhost:7100 xset fp rehash o running gdyntext with "-DDEBUG" enabled gives GDT: space width = 2 GDT: 34x 5 A: 4 D: 1 [Hallo Welt!] GDT: MH:5 LH:4 My system: linux-2.2.1[14] xfree86-3.3.5 glibc-2.1.2 gcc-2.95.[12] xfsft-1.1.6 only for ttf -- x-fonts and typ1 through the X-Server gtk+-1.2.7 The (script-fu gimp_text_get_extends ...) given on the console shows a resonable behaviour. Yours Uwe Koloska -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
Re: 1.1.19-installation fails
Marc wrote on Son, 09 Apr 2000: On Sun, Apr 09, 2000 at 12:50:57PM +0200, [EMAIL PROTECTED] wrote: It's a part of the gettext tools. On Linux you either get both or none. As some people already have said, this is wrong. Please note that I spoke of Linux not of any OS in the world. Me, too: linux configurations that only have msgfmt (and lack msgmerge and msgunfmt) _are_ quite common, at least according to the reports we got. AFAI understand the reports: Some (all?) distributions distinguish between gettext-normal and gettext-devel. The fist one has no msgmerge but the second, because it's thought of as an development tool. But since configure doesn't test for both parts (normal and developer) it guesses wrong at the presence of the whole gettext. Uwe -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
Re: Suggestion: disabling Perl-Fu installation if Gtk-Perl is not present
Raphael wrote on Mon, 13 Mär 2000: As an end-user, I prefer a stable application that may have less features than another that has more features but that crashes or complains that my system is not correctly configured. Hey, this is, why the most of us don't use Windoze, I think ;-))) Back to the facts: currently, anyone installing the Gimp on a "normal" UNIX system (i.e. from any major Linux distribution, or Solaris, and so on, that has perl but not the optional modules from CPAN) gets a version of the Gimp in which a large number of options do not work. I consider that as a serious bug. If a user does not have the opportunity to download and install the Perl modules from CPAN (no Internet connection, no administrative rights, whatever) then the best workaround for the moment is "make uninstall ; configure --disable-perl ; make ; make install". This is not a good solution. Yes, this is really not a good solution!!! What about making an extra package with all perl-modules required to run Gimp with all powerfull features? Someone (not me, because I don't even understand what happens while perl installs some package:-(() can package all needed Perl packages, make a simple but nice configuration (only install those packages not present) and give any user (not only the perl wizards) the possibility to use the whole power of Gimp. Some addition to the ./configure could lead to a message "You don't seem to have some important perl packages installed. If you wish to use Gimp with all it's power, grab 'gimp-perl-packages.tar.gz' and install it. Then run configure again." And (don't take this seriously ;))) this can solve a lot of documenation updates! Yours Uwe Koloska -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
GUI Bugs: Levels and Curves
Hello, I just tried to mimik some algorithm for enhancing the colors of an image taken by a digital camera (or a scanner, or ...) that was explained for photoshop (and works very well -- far better than the automatic). By trying this I found some things that have to be discussed (and maybe later reported as errors). But first I describe the algorithm. It is taken from an excerpt of a book about color correction: http://www.daton.de/wargalla/(german) auf dieser Seite gibt es einen Link zu "das BUCH" und dort diesen Algorithmus als Probekapitel 1. make the level of each channel (R, G, B -- _not_ RGB or value) spread from the beginning of the hills to their end (don't know the right english words) 2. take a color pick of some point that has to be gray (say: 123 / 115 / 139) 3. adjust the curves for each channel (again R, G, B, -- _not_ value) with only one aditional point, that all three values meet the middle one (123 in the example): R 123 - 123, G 115 - 123, B 139 - 123 Hope this was clear enough to be valuable. The problems that arise: - for levels and curves there are four channels R, G, B, value. Is the fourth one really "value" (from HSV) or is it the combination of the other three?? The latter one is called "RGB" in photoshop and I think this is clearer. - in curves it is not easy to discover what is the input (x or y) that is matched by the shown curve to the output. As someone a little bit familiar with maths, I can determine that x is input and y output but maybe it would be better to give these two terms directly (or are there problems with i18n strings in a picture?) - if the other two points are really bugs this one is not and though has to be delayed after 1.2: It would be very nice to enter the value for x (input) and y (output) numerical and not by carfully driving the mouse. Photoshop has (albeit since 5.0) two entrys that show up if a point from the curve is selected. Yours Uwe Koloska -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
mail to list not sender
Hello, if I want to answer some posting, I normally want it to go to the list, but because the list is not the sender and an "reply to" isn't set, the mail is addressed privately to the sender. Some times I'm able to change this behaviour -- sometimes not ;-)) Isn't it a good idea to add this "reply to: the list"? Yours Uwe Koloska -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
Re: [gimp-devel] Re: Some UI inconsistencies and a patch....
You wrote on Fre, 04 Feb 2000: On Fri, Feb 04, 2000 at 12:48:50AM +0100, [EMAIL PROTECTED] wrote: Since the menus were reorganized I am constantly guessing wether "Repeat Last" will repeat my last action, the one before or not work at all, since you can't tell from the menu anymore. Huh? Sounds strange, could you provide a snapshot in a private EMail? I can't image what this should look like "Repeat Last" will repeat the last plug-in. Since menus do not provide a feedback of wether an entry is a plug-in or "built-in" (I think it would even be wrong to do so), you have to know this, which is not easy for beginners. If there was no former plug-in action the menu stays active and suggest that something will be done. I think the first plug-in action has to change the state from disabled to active -- or there has to be a response "no plug-in to redo / reshow, etc.". Uwe Koloska -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
Re: Thanks (Re: Gimp splash images)
On Don, 13 Jan 2000 wrote the famous Carey Bunks: Don't you think, though, that it would be good if the GIMP had an identity? I think the marketing types call it something like "branding"...an image that when folks see it they say, "oh yeah, that's the GIMP". If the splash is always changing, I think it will just lead to identity confusion. For this reason, I'd prefer the brush over the random-splash-screen idea. But I still prefer the balloon over the brush ;-) Me too! But what did you think about the ballon picture (with it's poetic message of breaking the bounds and leaving the world behind) being painted by the brush (to include the statement that gimp beats them all ;-))? Hey, I am no artist -- and will never be :-( But I am a bit of a conceptionist :-))) Carey is right with the branding! Photoshop is known by it's eye, corel draw by it's balloon (so maybe the balloon isn't very well suited for the gimp), Illustrator by the venus and so on. So I think we have to start thinking about one concept that illustrates the power of the gimp. Let's make a brain-storm and start a hurricane of ideas! And then our well beloved artists can bring this ideas and concepts to life! Just my 0.02 euro ;-) Uwe -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
Re: [gimp-devel] Re: Feature wanted
Hey, let's have a look at the problem that started this thread: Juhana wants to get a color from some picture to paint on another. There was an easy solution suggested by Jukka: In gimp 1.1 you can use 'ctrl' to temporarily change to colorpicker if you are using one of the painting tools (pencil, paintbrush, airbrush, etc) So as this solves the initial problem a question arises: Does anyone know of a situation other than these, where a changing tool is important? If yes, collect this situations and find existing or pragmatic or new and innovative ideas! And to discuss the 'active tool' pattern: - what is it good for, if the tool changes -- but only the tool? You maybe have to remake all the other settings (brush, colours, etc.) - and if the whole context is fixed for a special image, you can't use the active tool to solve the ppp (picture palette problem). Just my .2 euro Uwe Koloska -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
Re: [gimp-devel] Re: Feature wanted
at they know of (it is not able to make table that have auml; look right) but are not willing to fix it ... Merry Christmas to all "Glory to God in the highest and on earth peace to those on whom his favor rests." Luke 2:14 Uwe Koloska -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
Re: Modifier keys
Austin wrote on Tuesday, 09 Nov 1999: Again, I'd recommend someone finding out what PhotoShop's modifiers do, and just blatantly copy them. I have two reasons for this: a) people used to PS will like this. b) some team at Adobe has already done usability testing - we can reuse their work. I have looked everywhere on the photoshop CD but there is no document describing the shortcuts in short. With Photoshop came a reference card and if someone wants to make it in a ascii table, I can send her/him a picture of it (but beware: it's in german). On the Adobe Website I have found a document called crossprod.pdf (214034 Byte) that show's CROSS PRODUCT KEYBOARD SHORTCUTS for Adobe Photoshop 5.0, Adobe Illustrator 8.0 and Adobe PageMaker 6.5 maybe this is a good starting point. If you can't find this doc at Adobe I can mail it or ftp it to a common place. BTW: AFAIS photoshop isn't consitent at all with keybindings -- but I don't use PS but Gimp ;-)) Yours Uwe -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
Re: Tile Cache Size
Nich Lamb wrote on Die, 09 Nov 1999: Why does my 7274 x 9985 RGB image (212743Kb of data by my calculations) result in the creation of a gimpswap which is up to 500Mb in size? Where do you think can the undo information reside??? Uwe -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
Re: Plugins
You wrote on Mon, 08 Nov 1999: Would it still be a problem for you if only the menu entry itself is english, but the english menu is sorted under the corresponding german standard menu (see above for "Add Selection")? Oh, it's not for me ;-) I think about all the "only" users. I use gimp in english and are satisfied (so I am searching for ways to make my system better). I think of it pragmatically: If there are no two (or more) menus with the same name (but in different languages) it is not really bad. It is not nice though! Think of it as a little gift just around the corner: "The whole gimp is in english. I understand it but I would prefer german. Oh, here in File are all entries translated -- very good." So what I wanna say: All that makes two menus of the same manner disappear is a bugfix. The other things like improvement of the i18n-Code to make it consistent and in toto able to translate all messages is the right thing todo after 1.2! Just my 0.2 Euro Uwe Koloska -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
