Re: RUN_WITH_LAST_VALUES
On 17 Feb, Austin Donnelly wrote: I've been meaning to find a way to update the menu item to include the filter name so you can get a better idea what will happen, eg: Filter-Repeat Last (blur IIR) or something. Great idea. In case you don't have the time to implement it please file it as an enhancement in bugzilla so we don't forget about it. -- Servus, Daniel
Re: Proposed Paint Core changes to support textures
On 6 Feb, David A. Bartold wrote: I think a better solution would be a definable pressure curve, much like Wacom's Windows driver has. That'd probably be a feature of the general mechanism you described and perhaps what you have in mind. Hm, generating a lookup table and getting the pressure from there instead directly from the driver would be trivial to implement and seems like a worthy feature to me. I made an entry into bugzilla so we don't forget that. I'd like to wait for Sven and Mitch to complete the changes so we don't have to implement this in several places hopefully. A user (or a brush designer) can define their own function and the mechanism would be usable for all tools, not just ones that draw by copying from bitmaps. Absolutely. The major problem with having different texture maps for each pressure is the amount of memory necessary to store them. Texture tiles generally are much bigger than brushes to reduce visible repetition. A texture of size 256x256 is not uncommon, and if there were 8 copies of that texture stored in a brush pipe file, each bitmap corresponding to a different pressure, then the file will be ~500k. That's a big download (and a lot of cache misses) just for one texture. Since many people download their copies of GIMP, that's a lot of bandwidth, too. But you can have different effects if you have the choice to use pressure-mapped-brushes as song as we don't have mathematical brushes because some tools (in reallife) behave quite differently when one applies bigger pressure to them. I'm not convinced creating bitmaps specific to certain values of parameter subsets (such as angle, pressure, velocity, random, ordering, etc) is really the proper solution. It works okay if you want to change a tool depending on the value of one variable, but each time a parameter is added, the number of bitmaps increases manyfold. Basically the whole mechanism explodes in an exponential disaster. ;) Sure, but since this is optional I don't really see the problem. For example: a 256x256 texture with 9 angles and 8 pressure levels will require more than 4 megs of memory. Who cares? People that like to use such a beast (have you ever tried the speed of HUGE brushes with any graphics application?) also have the necessary memory... it's like people that can afford a 1.4 GHz P-IV probably also have the necessary money but this is also just optional. :) -- Servus, Daniel
Re: How to get access to the new bug database?
On 7 Feb, Raphael Quinet wrote: Since the GIMP/GNOME bug database has moved to bugzilla.gnome.org, the administrative options have changed. On the old bugs.gnome.org, it was possible for me to change the status of some bugs easily, but now I cannot change the status, affected OS, priority and other features of the bugs. That's what I considered a bug with the old interface. I have been through the list of GIMP bugs and I know that some of them could be changed from UNCONFIRMED to NEW or NEEDSINFO. Correct. That's what I did all day. I also spotted several of them that could be set to "All OSes" instead of "Linux". Or some suggestions for enhancements (including some that I originally reported) that could be set to "Low" priority. I would like to help and keep the bug database up-to-date, but unfortunately Bugzilla does not let me change these options. OK, you now have the necessary permissions to change bugs. Since the Bugzilla home page does not mention any contact address, I am sending this slightly off-topic request to this list. If anyone know who to ask, please tell me. Thanks. If you had a closer look at the bugs you would know that they are all assigned to me feel free to take any amount of them. :) -- Servus, Daniel
Re: New wishlist for next GIMP available??
On 3 Feb, Sven Neumann wrote: has the wishlist for features for gimp 1.4/2.0 been started?? If so where can I find it/add to it? The source tree contains a file TODO which is a collection of ideas that have come up over the years. Actually the file should not be called TODO, but probably IDEAS or something similar. In case you don't know where to put your suggestion feel free to use the bugtracker for filing it (http://bugzilla.gnome.org). That way it won't get lost. -- Servus, Daniel
Re: Plugin patches
On 14 Jan, Jens Christian Restemeier wrote: I recently got a bug report for QBist, and in turn made a new version. What is the easiest way to get it into CVS-Gimp ? I made a patch, but the patches directory on ftp.gimp.org doesn's seem to be cleaned for 2 years, and the latest CVS version doesn't have the changes from the newest version on the plugin repository. Send it over and I'll review it. -- Servus, Daniel
Re: gimp patch 1.1.32-1.2.0 [Also: Re: cmon guys, no patch from 1.1.32 to 1.2??]
On 9 Jan, Christopher Curtis wrote: Patchsets also have a big problem which timecop already noticed: They don't contain binary files or patches to such and thus a patched tree might miss quite a few important files after a while. xdelta wouldn't cause that particular problem but is harder to use and deltas are not as obvious to read as an unified diff. I don't think that the majority of people applying patches really care what the format of the patch is (developers, of course, probably do, but not people like timecop or myself who prefer a xxxK patch to a xxMB download). They do; if we started now to switch over to deltas then quite a few people would complain about that. I definitely see the point, I'm behind a very narrow pipe as well so I prefer patches, too, but what is even more comfortable than patches is CVS, because they don't suffer from the problems patches do and are much easier to get and more complicated to mess up the source. I don't see a public rsync server for gimp, cvs or otherwise. Perhaps this might be an acceptable option for people with modest bandwidth capabilities. There are anonymous CVS servers for the GIMP. -- Servus, Daniel
Re: Suggestions for gimp
On 6 Jan, Sven Neumann wrote: The other ideas seem to be good suggestions. I think we should set up a web-forum where we collect ideas and suggestions like this. What about the bugtracker? It's much mightier now and a good place to keep things. -- Servus, Daniel
Re: the Gimp 1.2.0 for windows ?
On 5 Jan, Bennett Keith Portnet wrote: Sorry to bug you, I found you name and email address in the GIMP files ! I downloaded the GIMP 1.2.0 (for Windows ?!) from Tucows. It has been uncompressed into a file on my hard drive. (I am running Windows NT) NOW WHAT DO I DO TO GET IT RUNNING ? I can't find a file that runs it ! No idea, I have no Windows. I'll forward this mail to the developpers mailinglist. Maybe someone knows an answer -- Servus, Daniel
Re: PATCH: Iscissors patch for Gimp 1.2
On 1 Jan, Laramie Leavitt wrote: I have ported a part of my iscissors patch from 1.1.25 to gimp 1.2. All this patch does is add a livewire boundary to the iscissors tool, and an option in the tool options to turn it on and off. Yay! This is way cool. I'll checkin your changes to the new CVS head in a jiffy. While working on iscissors, I noticed that there was an error in converting the iscissors selection to an actual selection. Has this bug been fixed or should I track it down? Which bug? -- Servus, Daniel
Re: gimp patch 1.1.32-1.2.0 [Also: Re: cmon guys, no patch from 1.1.32 to 1.2??]
On 26 Dec, Garry R. Osgood wrote: The tarballs and patch-sets are really meant for end-users who prefer to compile from source, but don't otherwise desire to get involved in maintenance and so don't have a strong motivation to keep a bleeding-edge source tree around. Patch sets are published with this laid-back attitude in mind, They lack the CVS administrative files which is a pity (but then, CVS admin directories don't always transplant themselves effortlessly. They depend on the context of particular users on particular clients using particular CVS servers) Patchsets also have a big problem which timecop already noticed: They don't contain binary files or patches to such and thus a patched tree might miss quite a few important files after a while. xdelta wouldn't cause that particular problem but is harder to use and deltas are not as obvious to read as an unified diff. I also noticed the first problem a while ago and thus I had to refetch the whole tarball every now and then which is a pain over a slow line. Luckily our maintainer is kind enough to provide bzipped tarballs while the GNOME maintainers in general haven't got the clue yet. -- Servus, Daniel
Re: GIMP 1.2.0 and Solaris 7/SPARC
On 28 Dec, Tino Schwarze wrote: Without having looked at the code - what do we need that many FDs for?! We don't need to open all palettes at once, do we? The code for the brushes, gradients and the palettes is (was?) really nasty. But the file descriptors are closed after the complete palette is loaded to memory, if this is not the case on Solaris we should have a closer look on this one because it might easily eat of the whole systemressources. -- Servus, Daniel
Re: cmon guys, no patch from 1.1.32 to 1.2??
On 27 Dec, [EMAIL PROTECTED] wrote: You know since you take time to answer my posts, I might as well too. Compared to your "limited" 64k how does 9600 that disconnects every 5 minutes sound to you? And the fact that downloading something like a full gimp 1.2.0 would take close to 2 or 3 hours? And the fact that those 2-3 hours would cost me somewhere in the neighborhood of $5 PLUS telephone charges? Now go think again. You are such a whining moron. Why should I solve YOUR homemade problems? Now go think again -- Servus, Daniel
Re: cmon guys, no patch from 1.1.32 to 1.2??
On 26 Dec, [EMAIL PROTECTED] wrote: I am not supposed to download 10mb of source code, I have been patching up since like 1.1.20, no way, you can provide a good patch from 1.1.32 to 1.2.0. Why not use CVS and tags? Makes life much easier for both sides. -- Servus, Daniel
Re: RFC: The future of The GIMP
On 14 Dec, Sven Neumann wrote: Please keep in mind that the main intention of our proposal has been to better distribute work between core and plug-in developers by seperating the source trees during development. Perhaps this scheme could be translated to distribution too, but it does not have to. If we decide to continue to distribute an awful lot of plug-ins with The GIMP as we do know, we can always put them all into one tarball at release time. Or several smaller tarballs, or a single for each plug-in ... What I could imagine is something like an Plugin installer plugin which is able to handle various different formats a plugin may appear as like as a source tarball (if the user has the tools to compile it of course) and as binary files (I can imagine a central building cluster for that and I even might be able to provide that) for several architectures and even optimized for different systems. So depending on the needs of the user the plugin can either be build on his system or come already done. Of course the distribution wouldn't be restricted to HTTP or FTP but also be available for CDs. For some reason I'd really like this idea because I eases the GIMP quite a bit and we don't have to ship all the plugins with the GIMP. Hereby I'd also like to propose to change the naming of the GIMP libraries to a more obvious system. Instead of changing the libraries version with the GIMPs version I'd like to have it jsut changed when the binary compatibility can't be assured. This time one doesn't have to recompile the plugins every now and then. Servus, Daniel
Re: Tablet Troubles
On 20 Nov, the Loial Raven wrote:
I am using XFree86-4.0.1 and have noticed that my tablet is not
working properly...
Pressure sensitivity is the problem... it seems like gimp is either
getting a pressure of 0%, 100%, or some value higher that causes
feedback when using some paint tools. I was thinking it was a problem
with Xfree, but when i used the xinputev, i found it was giving proper
values...
There's a bug in the XInput driver for the USB version (thus I assume
you're using this one) which maps the pressure to a range between
0.25 and 1.25 instead of 0 to 1.00.
I'll attach you a fixed version. I still have to make some changes and
remove some crufty code, but this one should work. If you need the
module itself feel free to get back to me and request it for i386 and/or
PPC.
--
Servus,
Daniel
/*
* Copyright 1995-1999 by Frederic Lepied, France. [EMAIL PROTECTED]
* Copyright 2000 by Daniel Egger, Germany. [EMAIL PROTECTED]
*
* Modified for Linux USB by MATSUMURA Namihiko.
* FrñÅñÓic Lepied [EMAIL PROTECTED].
* Additional changes by Brion Vibber [EMAIL PROTECTED]
* and Aaron Optimizer Digulla [EMAIL PROTECTED]
*
* Permission to use, copy, modify, distribute, and sell this software and its
* documentation for any purpose is hereby granted without fee, provided that
* the above copyright notice appear in all copies and that both that
* copyright notice and this permission notice appear in supporting
* documentation, and that the name of Frederic Lepied not be used in
* advertising or publicity pertaining to distribution of the software without
* specific, written prior permission. Frederic Lepied makes no
* representations about the suitability of this software for any purpose. It
* is provided "as is" without express or implied warranty.
*
* FREDERIC LEPIED DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
* INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
* EVENT SHALL FREDERIC LEPIED BE LIABLE FOR ANY SPECIAL, INDIRECT OR
* CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
* DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
* TORTIOUS ACTION, ARISINGOUT OF OR IN CONNECTION WITH THE USEOR
* PERFORMANCE OF THIS SOFTWARE.
*
*/
#include xf86Version.h
#ifndef XFree86LOADER
#include unistd.h
#include errno.h
#endif
#include misc.h
#include xf86.h
#define NEED_XF86_TYPES
#if !defined(DGUX)
#include xf86_ansic.h
#include xisb.h
#endif
#include xf86_OSproc.h
#include xf86Xinput.h
#include exevents.h
#include keysym.h
#include mipointer.h
#ifdef XFree86LOADER
#include xf86Module.h
#endif
#undef read
#define read(a,b,c) xf86ReadSerial((a),(b),(c))
#undef write
#define write(a,b,c) xf86WriteSerial((a),(char*)(b),(c))
#undef close
#define close(a) xf86CloseSerial((a))
#define XCONFIG_PROBED "(==)"
#define XCONFIG_GIVEN "(**)"
#define xf86Verbose 1
#undef PRIVATE
#define PRIVATE(x) XI_PRIVATE(x)
static const char *default_options[] =
{
NULL
};
static InputDriverPtr wcmDrv;
#ifdef size_t
#undef size_t
#endif
#include asm/types.h
#include "linux/input.h"
#ifndef O_NDELAY
#ifndef O_NONBLOCK
#define O_NONBLOCK 04000
#endif
#define O_NDELAYO_NONBLOCK
#endif
#define INI_DEBUG_LEVEL 5
#ifndef INI_DEBUG_LEVEL
#define INI_DEBUG_LEVEL 0
#endif
static int debug_level = INI_DEBUG_LEVEL;
#define DEBUG 1
#if DEBUG
#define DBG(lvl, f) {if ((lvl) = debug_level) f;}
#else
#define DBG(lvl, f)
#endif
/**
* WacomDeviceRec flags
*/
#define DEVICE_ID(flags) ((flags) 0x07)
#define STYLUS_ID (10)
#define CURSOR_ID (11)
#define ERASER_ID (12)
#define ABSOLUTE_FLAG (13)
#define FIRST_TOUCH_FLAG(14)
#define KEEP_SHAPE_FLAG (15)
/**
* WacomCommonRec flags
*/
#define TILT_FLAG 1
#define GRAPHIRE_FLAG 2
typedef struct
{
int state;
int coord[3];
int tilt[3];
} WacomFilterState;
typedef struct
{
int device_id;
int device_type;
unsigned int serial_num;
int x;
int y;
int buttons;
int pressure;
int tilt_x;
int tilt_y;
int rotation;
int wheel;
int discard_
Re: brush and pattern popups (was Re: Gimp tool icons)
On 5 Nov, Tuomas Kuosmanen wrote: Just curious: Is anyone able to get the brush dialog by doubleclicking the brush in the toolbox using a graphicstablet? Dunno, I have it always open :) It works now... I fixed the driver so probably it was a problem in there -- Servus, Daniel
Re: GIMP help docs
On 6 Nov, Sven Neumann wrote: If you want me to change the helpbrowser, I need a detailed list of the changes that are necessary. just the changes we talked about: Removal of the HTML navigation bar and using the supplied links in this bars for the buttons in the helpbrowser. -- Servus, Daniel
Re: GIMP help docs
On 4 Nov, Garry R. Osgood wrote: Given the nearness of 1.2 release, the Gimp Help Team (bex, Piers Cornwell, Daniel Eggers apologies if I missed the other contributors) started a separate gimp-help project last July, and not integrate with the main tree until help stuff is reasonably sane, complete, and stable. This is now the case: The help is completely converted now and we found a way to compile it very nicely. We just need to integrate it now and get Sven to add some of the promised new and necessary features to the helpbrowser. -- Servus, Daniel
Re: brush and pattern popups (was Re: Gimp tool icons)
On 5 Nov, Austin Donnelly wrote: Is it generally known that mouse-down and waiting on brushes and patterns pops up a larger preview window showing the whole brush/pattern if it's larger than the preview? Do many users discover this themselves, or are they ignorant of the fact? Just curious: Is anyone able to get the brush dialog by doubleclicking the brush in the toolbox using a graphicstablet? -- Servus, Daniel
Re: Hispalinux talk / demo
On 28 Oct, Tuomas Kuosmanen wrote: No clue. Is this a "they want someone to do a demo" or "who the heck is going to do a gimp demo there??" BTW: I'm going to show GIMP at the COMDEX in Las Vegas at the SuSE booth -- Servus, Daniel
Re: configure, libtool the install prefix [2]
On 1 Oct, Marc Lehmann wrote:
I haven't fixed yet the GIMP Perl plugins installation, please could
anyone fix it or tell me a workaround?
The README.perl suggests PREFIX= for just this case. Daniel Egger
could probably get more info as he works for suse and suse has quite a
few perl packages in rpm format (includign gimp-perl).
We build the gimp-perl plugin from the CPAN sources and disable it in
the GIMP distribution because it makes too much problems there especially
on recent SPARCs, alphas and ia64. We don't use the BuildRoot features
of RPM however because it has some issues with Perl which Marco also
found :)
The important section from the gimp-perl package looks like this:
%build
CFLAGS="-DGIMP_ENABLE_COMPAT_CRUFT" perl Makefile.PL
make
%install
eval `perl -V:installarchlib`
rm -f $installarchlib/perllocal.pod
make install
install -d /var/adm/perl-modules
mv $installarchlib/perllocal.pod /var/adm/perl-modules/gimpperl
%{?suse_check}
whereas the necessary BuildRoot stuff from the MIME-Base64 Perl package
looks like this:
%build
perl Makefile.PL
make
%install
rm -rf $RPM_BUILD_ROOT
eval `perl -V:installarchlib`
install -d $RPM_BUILD_ROOT/$installarchlib
make PREFIX=$RPM_BUILD_ROOT/usr \
INSTALLMAN1DIR=$RPM_BUILD_ROOT/%{_mandir}/man1 \
INSTALLMAN3DIR=$RPM_BUILD_ROOT/%{_mandir}/man3 \
install
install -d $RPM_BUILD_ROOT/var/adm/perl-modules
mv $RPM_BUILD_ROOT/$installarchlib/perllocal.pod $RPM_BUILD_ROOT/var/adm/perl-mo
cd $RPM_BUILD_ROOT/usr/lib/perl5/site_perl/5.*/*-linux/auto/MIME/Base64
cat .packlist | sed s:$RPM_BUILD_ROOT:: | sort -u .packlist.n
mv .packlist.n .packlist
cd $RPM_BUILD_ROOT/var/adm/perl-modules/
cat MIME-Base64 | sed s:$RPM_BUILD_ROOT:: MIME-Base64.n
mv MIME-Base64.n MIME-Base64
Using PREFIX for installation doesn't seem to work for all packages,
though...
--
Servus,
Daniel
Re: configure, libtool the install prefix
On 1 Oct, Marco Lamberto wrote:
I've got a little trouble while rebuilding the rpm of gimp 1.1.26,
when running the "make prefix={a_new_prefix} install" it tries to
install into "/usr" discarding the "prefix" and "PREFIX" values. I
should update someting or someone has forgotten something? ;) Actually
You shouldn't use make prefix=something install. This is mostly useful
for buildrooting rpms but may produce silly results for everything else
(because programs may have a different prefix hammered in at configure time).
So if you want to get GIMP to a different place use: configure --prefix=something
and then: make install.
--
Servus,
Daniel
Re: Using Gimp as HB's imaging library.
On 28 Sep, Alejandro Forero Cuervo wrote: Could someone please help me? Where should I look at? I am unfamiliar with Gimp's code, as you can see. GIMPs scripting features are all plugins, thus you should see pluins/script-fu and plugin/perl how they implement thing and whether you can use that code as an interface. If you'd like create your own plugin libgimp is the right place to look... -- Servus, Daniel
Re: *BUG REPORT* - gimp 1.1.26 and jpeg saves
On 29 Sep, Garry R. Osgood wrote: I cannot reproduce this bug under any circumstances here on i386 while it crashes Kevin's machine hard. Should the dialog block while a update is running? Just asking because it does here and elsewhere not I reproduce it here on both the laptop (Intel PIII RH 6.2) and SGI (Indigo, O2 Irix 6.5.8) on current (well, Thursday current) CVS Gimp. More often on low resolution slider settings. To be even more concrete it doesn't just block the dialog while an update but also delays the optionchanges a few seconds before the next one. Don't ask me what I was smoking but it works perfectly here :/ -- Servus, Daniel
Re: *BUG REPORT* - gimp 1.1.26 and jpeg saves
On 28 Sep, Steinar H. Gunderson wrote: H... Since the JPEG previewing mess originally was made by me, I've just got a side note: libjpeg is rather unstable at low qualities. Of course, if this happens with HQ too, it is a GIMP bug, and not a libjpeg bug. I cannot reproduce this bug under any circumstances here on i386 while it crashes Kevin's machine hard. Should the dialog block while a update is running? Just asking because it does here and elsewhere not -- Servus, Daniel
Re: *BUG REPORT* - gimp 1.1.26 and jpeg saves
On 28 Sep, Paul Wagland wrote: First up, I hope that this is the right place to report this bug. Second thing: This is a great product. You guys should be proud of yourselves! We are, hehe :) Now back to bussiness... :) I have no reason to believe that steps 1-2 make sweet rafoosle difference. I suspect, but of course cannot verify :-) that this is a threading issue, since if in step 6) if I press the key one step at a time then the problem does not occur. Also, if I make the image "large enough" the problem does not occur. Maybe the preview engine stomps on something while it is being read by the main window? My guess is that "large enough" is anything that takes long enough to encode that the drawer is definitely finished with it by the time the new image is overwritten. I am guessing this based on the Gtk error messages, but have never looked at the code, so should probably let you folks do that :-) Kevin Turner and I have been hunting this one yesterday. Unfortunately I cannot access bugs.gnome.org at the moment but the number starts with 12*** and you'll find it at the place for critical bugs. He provided a really nice backtrace, too. We found out that this bug just occurs with an open layersdialog and that different bugs occurred on his machine when this is not the case. Unfortunately I cannot debug it because this error doesn't show up on my machine; prerequisite for it is that you change one of the parameters while an update of the preview is running in the image display. However the dialog is blocked on my machine (which seems sensible to me) by default and I'm not quite sure why -- Servus, Daniel
Re: TODO for 1.2 release
On 26 Sep, Tim Mooney wrote: Grepped through the source and couldn't find any C++ style comments... cc: Error: lighting_ui.c, line 387: Invalid statement. (badstmt) // GtkWidget *spinbutton; --^ This is from 1.1.26/plug-ins/Lighting. I haven't made the build proceed any farther, to see if there are others. Perhaps it's been fixed in CVS already, and that's what you're looking at? No, it's not fixed in CVS but for some reason find -name *.c | grep "//" - didn't work as I would have expected it. Will grep it manually and replace every C++ comment by a C comment. Thanks for pointing out! -- Servus, Daniel
Re: TODO for 1.2 release
On 26 Sep, Tim Mooney wrote: You need to quote the '*.c', it's getting expanded by the shell before it ever gets fed to find. :-) Actually that's not the problem since there are no *.c files in the directory I started the search in... Anita:/mnt2/src/gimp # find -name *.c ./libgimp/gimpsignal.c ./libgimp/gimpwidgets.c ./libgimp/gimpchannel.c ./libgimp/gimpexport.c ./libgimp/gimpbrushselect_pdb.c ./libgimp/gimplayer_pdb.c ... That's not the problem. For some reason the grep failed :/ -- Servus, Daniel
Re: gimp-help: markup conventions
On 6 Aug, Kevin Turner wrote: gimp-help/whysgml.txt states that we are going to go through all the bother of writing well-formed XML files (e.g. being strict about always using closing tags, etc), but that we won't be actually marking the files as XML. If you have a grudge against xml, why bother being half-compatible? I'm a bit puzzled by this fence-sitting stance. If anyone is afraid that the XML tools are Not There Yet, remember that the tools that work with DocBook in its SGML form work with DocBook/XML too. However the DTD you were using for the maze plugin is more like a experimental hack. I you like to have the real XML DocBook you might consider using the version 4.0. I personally have no problem using DocBook/XML 4.0 versus using DocBook/SGML 4.0, however we should consider using ONE of them for the whole project because everything else is a mess. And the conversion from one to another is pretty simple as (like you stated) we already conform to most of the xml conventions. Please note, that I took notice of DocBook/XML just 5 days ago and that it's not really advertised on www.docbook.org, thus I didn't really know that Jade really works fine with that. I feel the on-line help is a reference, with distinct entries for specific parts of the application. A help entry for a filter is like a man page for that filter. I feel DocBook's "refentry" is the best fit for this. Hm, I'll have a look whether that can be integrated in a seamless fashion. If yes, why not To address or link to some part of the document, that part needs to be tagged with an ID. How shall we organize that namespace? For filters, I might use their PDB name, but some filters may have more than one PDB entry. And much of the help system is going to be describing user interface elements with no PDB name, so that's probably not a good plan. You normally shouldn't give subparts of your document id's and the naming for the mainpart of it should be pretty obvious, it's the name of the dialog or the plugin you're describing. However if you like to link to subparts of your document give it an id like: maze-001, maze-002 and so on... that should solve the problem. Of course if we have a plugin with the same name like an internal function we have to choose a different name, but that really shouldn't happen. There needs to be a regular way to construct a refentry's ID, and also a way to ensure all ID's inside that refentry are unique to that part of the document (so my "width" section doesn't end up pointing to something about cropping without meaning to). See above. Of course you also may name this section (applied to the maze example): maze-width. A man page usually has a "Credits" and/or "Authors" section. Do these belong in the help page? I'm guessing not, but it's not like plug-ins have About boxes or anything. Are you asking about the Authors of the document or the plugin? BTW: Please Kevin consider making a ChangeLog entry when you check something into gimp-help, thanks -- Servus, Daniel
Place of the new docs in the CVS
Hiho! I'm actually asking myself where we should place the new docs in the CVS. It seems we have two choices: 1) Put them in help parallel to the other files 2) Create a new directory for them until everything (automatic creation of HTML docs and indexing) is working good enough for production use and we have more files translated to SGML. I prefer the second solution because this won't render the old help system useless in the meantime and can be easily removed for new releases. Thus I'd suggest making a new dir "newhelp" for our work... -- Servus, Daniel
Re: Place of the new docs in the CVS
On 4 Aug, Michael Natterer wrote: Just go ahead and populate this directory. In the first time we'll take care of committing the generated help files into gimp. Once the build system is working (hopefully soon) we can include gimp-help as a virtual module into the gimp CVS tree. We'll start adding the things we've already done. Every of this files can be used alone thus we can just go ahead and produce HTML files for our context help. However we may need to tweak the output a little before we can use it with the helpbrowser, I haven't had the chance to test it with the gtkxmhtl library yet. Apart from that the SGML approach seems to the right thing to do (TM) i.e. it looks very promising. What still needs to be done are Makefiles, more documentation, scripts for automatic generation of indexes, translations, stylesheets (DSSSL) for a output which fits our needs best, stylesheets (CSS) for optimized view in enhanced browsers, etc... most probably not in that order but still... :) Our coordinator Piers will keep you up-to-date. -- Servus, Daniel
Re: Perl Scripting
On 30 Jul, Marc Lehmann wrote: i would really appreciate if you would finally start thinking, as this is not the first time you claim things that are sooo obviously broken :( No need to get insulting. Spend your time fixing the plugin instead. This would be more helpful for you and me. I can supply you all the information you'd like to have. BTW: You told me to just close all bugreports reporting gimpperl on the bugtracker, but I really think there could be serious problems which would need the time of an expert (i.e. you) to have a closer look. -- Servus, Daniel
Re: Perl Scripting
On 30 Jul, Marc Lehmann wrote: It's you who is unprof(f)essional. You were and are totally wrong with your today's claim about gcc -- claiming some not-yet-existant version of gcc causes problems on your machine. Pardon? Just because a version is not officially released doesn't mean it doesn't exist, does it? I'm forced to use a gcc version later than the LAST OFFICIALLY released version because I'm having severe problem with the C++ frontend in 2.95.2. I claim I'm using the CVS version from today which is obviously more rencent than 2.95.2. Now please tell me, where's my thinko??? I am not. However, unless you tell me about it I will have no way of finding out. Ok, I told you that you can't compile the plugin with a CVS version of gcc. There will be surely a new release somewhen so even more people will notice it, so fixing it before that will happen seems sensible to me. For example, when I told you that your latest patch uses mempcpy, a function not available on most systems, you just replied with a quote from the libc info pages(!), claiming the function _does_ exist. Sorry Marc, I told you very clearly that this shouldn't have been in the patch since it was just a try that has never worked anyway but since you told me in a very selfconfident way that this function hasn't ever existed I replied with a quote of the info page! That's the fact, anything else is pure speculation from your side. [ Rest of speculations deleted ] Marc, I just want to know ONE little thing: Will you help to make the gimpperl plugin usable on more systems (for example on future gccs), YES or NO? -- Servus, Daniel
Re: Perl Scripting
On 30 Jul, Marc Lehmann wrote: No need to get insulting. It's pure fact. You keep claiming all sorts of funny things that you yourself should have known long before you started posting about it. Ok Marc, it's enough. I will not continue this useless flamewar! In real life you sometimes play the nice guy but back on the computer you're pretty unproffesional! And I think otherwise. Don't ask me if you are going to ignore me. I wouldn't answer if I had ignored you. The perl plugin is broken on several configurations and you're ignoring it. If you don't want to help, let it be and do whatever you like to do. I for my part offered help to remove the problems but am pretty clueless since I don't know much about perl, otherwise I'd fix it on my own. -- Servus, Daniel
Re: Perl Scripting
On 30 Jul, Robert L Krawitz wrote: Pardon? Just because a version is not officially released doesn't mean it doesn't exist, does it? For this purpose, I would say it does (mean that it does not exist). Especially since it isn't even a formal snapshot (which egcs was doing for a while), but rather just the current development tree. Ok, then it's a formalistic problem. Unless the change has been announced as permanent, you have no idea what future gcc's will look like. OK, that's a good point. Seems like we'll be talking about this issue again when the release the next version Just for reference: GIMP and all other plugins work fine with most "versions" I've used so far... -- Servus, Daniel
Re: Perl Scripting
On 30 Jul, Andrew J Fortune wrote: I currently have the latest developers' version of GIMP (v1.1.24). Can someone tell me if Perl scripting is still available ? (...there used to be any entry called "Perl-FU" on the Xtns menu). Perl normally should be there. But since the Perl plugin has never really worked (greetings Marc! :) it's not a big phenomenon that it doesn't work for you... Maybe the compiler gave up at the try to compile the plugin. If you tried to build it on your own, please have a look at the problem and then tell us some details. Otherwise just email the producer of your package for some explaination... -- Servus, Daniel
Re: Gimp to MacOS
On 21 Jul, Michael Natterer wrote: I guess that Gtk+ and Gimp will run more or less automatically on MacOS X' BSD API once there is an X server, so there should be no need to "port" it. A X server for MacOS is due to be released by Apple, soon -- Servus, Daniel
Re: The Gimp is wasting a lot of memory
On 20 Jul, somnorici wrote: I set the undo levels to zero and loaded an image. 9376 by 11488 pixels grayscale is 107,711,488 bytes. My display depth is 16 bits. It didn't take long to link this with the swap file, which after loading the image was 292,421,632 bytes, plus the 32 megs of tile cache (it's on a 64 megs machine used for testing), it kinda equals three times the size of the image. The raw data are 105 MB without alphachannels, layers or something else. GIMP may be more efficient with memory, but I don't think it's such a big issue which would lead us to reconsider the memory management before our 1.2 release. 64 MB of main memory won't make you happy with that imagesizes anyway -- Servus, Daniel
Re: Gimp to MacOS
On 23 Jul, Charles Iliya Krempeaux wrote: Will it be free? Will it be a standard part of MacOS? (Or is it something Mac users will have to pay for?) Sorry, I have got no details handy. Read about it on slashdot or somewhere. Have a look at the usual MAC places to get info about that... -- Servus, Daniel
Re: Gimp to MacOS
On 23 Jul, Charles Iliya Krempeaux wrote: OK, I'll do that (eventually). But my point is, if X Windows isn't available on every Mac system... or at least if they can't get it for free... then it is worth porting the GIMP (and GTK+, GDK, etc) to the native MacOS API. I'm not against a port. If you'd like to do that, feel free to start hacking. As soon as I have my G4 box I may start helping you but until then you have to find other poeple with knowledge of Mac API's and stuff like that to port gdk over to it -- Servus, Daniel
Re: Color Quantization
On 26 Jun, DrMartin.Weber wrote: I took several months' time to compare nearly all available color quantization algorithms. Shurely GIMP's Median Cut is good but not the best. SQC (http://www-dbv.cs.uni-bonn.de/quant/) is really the best one available and it is also fast. I have some code for this that I'll upload the next days. It is buggy and written in a bad C style. I think GIMP should use this best available algorithm. I do not find the time to port the code to GIMP. So if anyone is interested, feel free to contact me. We're due to release GIMP 1.2 in the near future. It's a little bit to late to introduce a new quantization algorithm right now. With GIMP 2.0 we'll have the chance to let advanced user choose his preferred algorithm... -- Servus, Daniel
Re: License of the XCF loader in Imlib2
On 25 Jun, Sven Neumann wrote: I agree with this opinion and would be happy if we could set up a short email that we send to the Imlib2 people signed by some of the people owning the copyright of the affected code. Since it seems not necessary to involve Peter and Spencer at this point, some of the people who have made changes to the code should be ok as senders. I'm short in time right now. Who wants to set up an apropriate email ?? I'm waiting for an answer of the person who checked in the code. Maybe we should wait for his mail before considering further steps? -- Servus, Daniel
Re: License of the XCF loader in Imlib2
On 25 Jun, Nick Lamb wrote: It "appeared" courtesy of someone identified only as "cK", hopefully those working on Imlib2 will know that handle (though who knows, it doesn't look like an expertly managed project to me, maybe anyone can get CVS write privs) and remove their write privs. This code has been checked in by Christian Kreibich. Maybe we should contact him first... -- Servus, Daniel
XCF code in Imlib2
Hiho! I talked to Christian Kreibich, the author of the codemixture and he told me that it was a mistake to publish the code in this form and that he'll undo that step. He and Raster are going to meet next week and then they'll think about possible solutions for this conflict. -- Servus, Daniel
Re: XCF code in Imlib2
On 25 Jun, Marc Lehmann wrote: He and Raster are going to meet next week and then they'll think about possible solutions for this conflict. Don't they think this is demanding some _action_ (like reverting that patch)? "meet next week" and "possible solutions" sounds, well, not very serious. The patch IS already reverted. About 5 minutes after my mail... -- Servus, Daniel
Re: Greyscale crash
On 14 Jun, Sven Neumann wrote: app/pixel_region.c 1.20 app/paint_core.c 1.90 app/paint_core.h 1.30 app/undo.c 1.60 and couldn't see any problems. I could reproduce the crash after reverting all those changes, so it seems the problem is elsewhere. Okay, traced this problem further. The debugger says GIMP is dying while trying to g_realloc some mem for a brush in temp_buf_resize but I can't see anything strange going on there i.e. the addresses have been valid before and size is != 0. Could it be that someone freed that memory just before we're trying to use it while painting? Why does this problem only occur while we're using color brushes on grayscale images and painting on the edge of the image (i.e. the brush gets clipped)? And why the hell do we realloc the memory even if NOTHING has changed? -- Servus, Daniel
Re: Greyscale crash
On 14 Jun, Sven Neumann wrote: app/pixel_region.c 1.20 app/paint_core.c 1.90 app/paint_core.h 1.30 app/undo.c 1.60 and couldn't see any problems. I could reproduce the crash after reverting all those changes, so it seems the problem is elsewhere. ME TOO. GIMP tries to free unexistant memory. Unfortunately I can't tell where the logic fails at the moment. Anyway: While debugging this one I saw quite a lot of memory allocations going on for just a single dot on the screen... this is quite wierd -- Servus, Daniel
Re: label DB
On 13 Jun, Daniele Medri wrote: My idea is.. to create a db (..probably with PostgreSQL) to manage all the label of gimp, script-fu, gimp-plugin e make a coherent work with these labels for translation. A php-interface could be a nice add-on that i want to. Talk to Marc, he showed something like that at GimpCon -- Servus, Daniel
Re: SWF format...
On 23 May, Nick Lamb wrote: Having just come back from WWW9 I'm pretty enthusiastic about SVG right now. I can't see the point in continuing to use Flash once there are vendors clambering over each other to produce the best SVG plug-in and (since it's free) it will be built-in on Mozilla eventually. A little bit offtopic but: Mozilla already supports parts of SVG though it's not part of the default built. -- Servus, Daniel
Re: 1.1.19-installation fails
On 8 Apr, Marc Lehmann wrote: Yes, I got the impression from all what I was told: a) msgmerge is not checked for by gettext itself b) binary .mo files are being distributed with the gimp Since I was no gettext expert, I just ate it. But now we know better: a) is wrong, since msgmerge is a gno-only thing and b) is bad, since mo files definitely are not portable. Not distributing the .mo files with the GIMP would mean that every one who wants to compile it her/himself has to have a working set of gettext tools. Would be no problem for me, BTW... 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. I'm afraid I didn't get your point here; If you have the GNU gettext tools installed you'll have all of them, if not you'll have none. There is no inbetween. Please note that I spoke of Linux not of any OS in the world. Do the GNU gettext utils work for let's say Solaris, too? If yes, why not rely on them, if we do so on Linux, too? I think it would not be the worst thing if we had somebody with working knowledge of i18n. As it seems, we do not not have such a person :( You are so nice to me... :) -- Servus, Daniel
Re: Gimp Wishes (efficient trivial wishes)
On 1 Apr, Marc Lehmann wrote: I think using optional(!) tags (which will be more verbose) will be even more useful: Not much added strain on the programmer, not much strain on translators (we need one more translator for the en mapping). Please note that adding "tags" to the messages will mean that GIMP isn't usable any more without catalogs which is not very sensible IMHO. I'd rather refine the messages to have more variance in the texts... -- Servus, Daniel
Re: Gimp Wishes (efficient trivial wishes)
On 30 Mar, Stanislav Brabec wrote: I18n wishes: -- Please do anything with the fact, that main panel menu with default GTK theme can contain exactly 15 letters. Too few for three items inmost languages. What exactly would you suggest? That's actually a matter for the translators, not for the developers, as we don't know all the languages around the world. :) Ad translation problem: | 2. Gettext problem. | Sometimes you absolutelly need to translate same message differently. Tell it the programmers; they will have to add "prifixes" to make the strings different; e.g.: That's not meant to be serious, is it? It would be really a pain-in-the-ass to maintain this, even in the most simple case. Please consider that every language has other problems with those messages and trying to fix everthing with this idea would probably mean that EVERY message is used ONCE, which would be a kind of overkill. -- Servus, Daniel
Re: Gimp User Installation Dialog.
On 25 Mar, Blue Lang wrote: A lot of laptops, especially running linux @ 1024x768, will only support 8 bit depth. Dunno if it matters to ya or not. :P Gimping on the plane, ahh. Really? But that's not a limitation of the notebook I hope... The techniques used in notebook LCD's allow normal notebooks to run at full 15/16 bit or even in simulated 24/32bit (the circuts convert the real 20bit to 24 or 32bit) -- Servus, Daniel
Re: Gimp version number in $prefix/lib/gimp/* path names?
On 10 Mar, Raphael Quinet wrote: P.S.: I identified this problem when I tried to start an old version of the Gimp in order to check why the "Frosty" script was not giving the same results as in 1.0. If anybody knows why this logo script does not produce the same effects as it used to create, please tell me... I guess the problem you're describing comes from a change in the sparkle plugin. The are some other scripts, too, which don't produce the same quality output as earlier GIMP versions. -- Servus, Daniel
Re: Why host plug-ins at SourceForge? (Was: I want to develop IPTC-data support for The Gimp.)
On 26 Feb, Kelly Lynn Martin wrote: It will also force us to develop tools for the separate compilation of plugins and develop a plugin interface that is versionable The first one is definitely a need but "a plugin interface that is versionable"? We do have versioned libraries ensuring that plugins always use the right libgimp version and a wireprotocol which checks whether a plugin is using the same protocol version as the GIMP. -- Servus, Daniel
Re: Testing and integration of The i18n solution(TM)
On 25 Feb, Sven Neumann wrote: Which is exactly what I proposed at the end of my last mail. Despite that I proposed to build up the menu-structure (actually only the strings) in a hash-table before actually creating it. For a new translation function I guess? Would be much faster then going through gtk+ for each and every menu just to know if there's already a matching menu. It shouldn't be that complicated, but that depends on the internal representation of menus which I didn't look at. We'd end up with a hash containing all possible menu-strings with their translations as key-value pairs and would use that table later instead of calling gettext again. Uhm, no, that's not what I had in mind. This could be hacked in about 20 lines of code using a GHashTable, but I still consider this unnecessary bloat... Look at the code we already have to add the tearoff menus. A similar thing could be used to create the branches itself. I'm leaving home in a few minutes and after spending a whole night on other problems I'm very glad to have a look such an improvement. Don't expect a solution before 17:00 CET... -- Servus, Daniel
Re: Testing and integration of The i18n solution(TM)
On 25 Feb, Sven Neumann wrote: Don't waste your time at that. I already did that and I tried to explain you why there is no way to hook into that place since GTK+ creates the submenu on the fly. At the time we create the tearoff menu, the submenu is already created. But when the submenu is created, the menu_translate function does not know the complete path and therefore can't lookup a matching translation. Hm, but I think I nearly got it. Unless I have overseen something obvious, the only way to go is to analyze the menu strings on our own before we actually build the menus using gtk+. The more I think about it, the more I feel it might be worth to try the implementation I've proposed. Eventually this weekend... Please wait a moment. Otherwise we'll work again in different direction. BTW, is there a function to unbind from a textdomain? No. There's actually no need to hold the plugins translation tables in memory after the menus are created and we only need such a small portion of it. Or are the message catalogs properly shared if multiple apps use the same catalog? With gettext? You must be joking. I've never seen such a bad implementation of anything. -- Servus, Daniel
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: 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: 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
Re: PROPOSAL: New i18n solution
On 23 Feb, Sven Neumann wrote: gimp_plugin_add_locale_domain (gchar *domain_name, gchar *domain_path) and can only be called in the query function of a plug-in. The domain_path may optionally be NULL. Proposals for a better name are welcome. 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. Daniel, if we can agree on this solution, I would like to check this code in, so that you can work on adapting your code to the framework. I sent a newer patch in my last mail. It should do everything we need for now. I totally agree with this solution, so let's finalize it and get it into the tree. 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? -- Servus, Daniel
Re: PROPOSAL: New i18n solution
On 23 Feb, Sven Neumann wrote: No, that won't work. Of course you need to hook somewhere into plug_in.c or at least use the plug_in_defs list. Otherwise plug-ins won't be able to register their domain on the first call. Of course you are right, just a braino. The only thing missing now is the pluginrc write code. Huh? The info is already written into the pluginrc! I didn't say what I mean (TM), I meant the PDB code. New patch appended. -- Servus, Daniel diff32.gz
Re: Coding style (was: PROPOSAL: New i18n solution)
On 22 Feb, Raphael Quinet wrote: I did not like the GNU style at first (especially the space before the opening parenthesis) but now I understand that it is very important to keep a consistent coding style in each project, because it keeps the code manageable and maintainable. So I always use whatever coding style is recommended for the each project, even if this means that I have to format my patches differently for the Gimp and for a Linux driver, for instance. Since the Gimp uses the GNU style, I think that it is important to follow the GNU coding guidelines faithfully. Okay, will turn from the Standard vi indention into GNU coding style. BTW: While browsing the code I saw some file not matching ANY standard like xcf.h. It has neither a GNU header nor any guardings It's not that much code, and does fix a gaping hole in the i18n framework for plugins not distributed with gimp. Especially if we want 1.2 to last a while.. That's absolutely right. Yup! Me too (tm). Glad to hear that. -- Servus, Daniel
Re: PROPOSAL: New i18n solution
On 22 Feb, Sven Neumann wrote: With the usage of static array and buffer lengths you demonstrated in your patch it will most likely introduce one or two new bugs, but that could easily be hacked up a little cleaner Of course I could have used a linked list, but I'm not sure if it's worth using it. I also don't like the format of the localerc you proposed since it doesn't look like the other files in ~/.gimp-1.1. Why not use the scheme-like syntax people are used to use and that the gimp can parse anyway? I'd like to avoid having to extend the parser from GIMP because I don't need much functionality and this would surely introduce more bugs. But if this is a real concern, then I'll do it together with point 1. I'm not yet convinced that this goal is worth all the hassle. What do other people on this list think about this? If we don't change it know we'll be shipping 1.2 with crippled localisation support, since the number of plugins is increasing constantly and we're trying to get rid of some in the main distribution I really thing that something like this is a really must-have. -- Servus, Daniel
Re: PROPOSAL: New i18n solution
On 22 Feb, Manish Singh wrote: True, although we have a couple other inconsistencies already. The coding style needs to be the same as the rest of gimp though. I tried to bring it as near as possible. Of course a lot things could be better It's not that much code, and does fix a gaping hole in the i18n framework for plugins not distributed with gimp. Especially if we want 1.2 to last a while.. That's absolutely right. -- Servus, Daniel
Re: Coding style (was: PROPOSAL: New i18n solution)
On 22 Feb, Federico Mena Quintero wrote: I don't know if this will be useful at all, but the GNOME Programming Guidelines has a snippet for .vimrc to set the Linux kernel indentation style. This is the standard vim style. If you tweak it a bit it may work for GNU indentation style. No, unfortunately I couldn't get vim used to GNU indention style. Please tell me if this works or if you had to change something; I'd like to keep that part of the programming guidelines as accurate as possible. It'd work, but not for GIMPs code. :/ -- Servus, Daniel
Re: Coding style (was: PROPOSAL: New i18n solution)
On 23 Feb, Marc Lehmann wrote: Then, most probably, you have a very very old or broken version of vim (or maybe you use another editor, or vim in vi-emulation mode). Actually it's the latest stable version of vim. The whole point of these options is to make indentation automatic and more-or-less gnu-style. I was told that the style I used before is not acceptable as GNU style so I guess it's the less in "more-or-less". In any case, giving "my editor does indent differently" is a very poor reply to a request to follow a specific coding style. Well, Marc, if you followed this list then you'd know that I already posted an well indented and improved version of my patch. It was just a kind of a BTW note that I can't bring my editor to automatically create this indention style. You can write gnu-style using any non-broken editor! So if your editor does indent differently, use the keys of your keyboard to correct your editor, or read the docs on how to persuade your editor to do it for you. This seems impossible, but fortunately indent is working quite nice for me so this is now just an annoyance no "problem" anymore. -- Servus, Daniel
Re: PROPOSAL: New i18n solution
On 23 Feb, Sven Neumann wrote: The current solution for the plugins distributed with The GIMP works reasonably good. Really? I wouldn't call "we have to pre-add the menuentries to GIMPs core source otherwise it wouldn't work" working good. Actually my patch doesn't really address those problems, but the current code for plugin localisaing is more or lass an evil hack. I don't see why we should ditch the hardcoded path in favor of a config file the user will be able to mess with. I thought your proposal would only be a hook for additional plugins?! It was meant such, but from your description it seemed to me that you'd like to add those entries to ALL plugins. From your answer I can see that this was just a misunderstanding. Sorry, Sven. But this make it even harder to modify the parser like you'd like since it's only usable for a fixed number of arguments. It would work to insert those parameters before the pdb-args but that would a) be incompatible and b) mean that every plugin must have such an entry. I was speaking about the fact that whatever solution we come up with will not be backward compatible. Of course it will or at least should try to be. My current solution for example is. And your suggested solution will also as long as you don't touch the wire protocol. I will have to look through the code in app/plug_in.c a little more, but I think I was wrong in my last mail and there's no need to change the wire protocol at all. It would be really bad to do so. And even worse: This code is very simple to break, just look at it and it won't compile on DEC Alpha anymore; another look and it will cause every plugin under Solaris to fail. :( The amount of code-changes is IMHO more or less equal. The small feature you want to add should be well-thought and I don't see why you simply wipe away the arguments have I put up against your solution. Of course I try to wipe them away if they seem not reasonable or correct to me, that's how argumentation works. HOWEVER this doesn't mean that I don't care about your thoughts, they are really helpful and result in new ideas in my head. Just to clarify what I do think of: I'd like to have this done as simple as possible that means: - No PDB calls - No wire protocol changes There should be a simple libgimp call which allows plugins to register themselves in a new domain. If the domain is already available, check whether the path matches (not done in my patch yet!), if not simply add it. The GIMP on the other side should simply be able to get all the registered domains and to do the right things when gimpgettext() is called. Sven, your ideas are very nice but they are neither simple nor so easy to implement like mine. Please consider that we have already feature freeze, are trying to get a stable version out and just don't have the time for a fullfeatured platinum solution. Don't tell me that you have spent days to create your patch and don't want your hard work to be discarded. Sarkasm on GOD, I spend days without anything to eat and drink in my room just to get this idea into a working patch. PLEASE don't blow it away! Sarkasm off Sven, if you have good ideas, tell them to me and the world, any ideas are really appreciated. My only goal is to do my very best to get a new stable release of this great project done ASAP. I don't care about anything else at the moment and would rather like to concentrate on the GIMP instead of wasting time with flaming. -- Servus, Daniel
Re: the .po filename domain
On 21 Feb, Marc Lehmann wrote: I have a question: what standard do the po-filenames follow? In the current gimp, we have a en_GB translation, however, GB is not a toplevel domain, but the iso-3166 code for the UK. On the other hand, we also have uk (which is a toplevel domain, but not for ukraine), however, the iso-3166 code for ukraine is ua. So something seems wrong here. I *think* the easiest thing would be to standardize on iso-3166 and rename uk.po to ua.po. This is the right solution. AFAIR do all the other packages the same. -- Servus, Daniel
Re: pathsP.h
On 21 Feb, Blue Lang wrote: did that. :) if you have time, would it be possible to get someone with better bandwidth than i to download a clean copy of CVS gimp and see if it builds? Yes, it builds it's in our SuSE internal database i've done distclean and autogen, etc, etc - apps/pathsP.h is still not in CVS (and there still seem to be dependancies on it,) and the intl/ dir stuff still stops the build cold. Should 1.1.17 build w/out gnu gettext if I configure with --disable-nls? It should, this isn't tested thoroughly though, because we expect people being tough enough to test the CVS version to have all the necessary utils including gettext-0.10.35. -- Servus, Daniel
Re: An experiment (was Re: Move help menu item...)
On 13 Feb, Kelly Lynn Martin wrote: This can be dangerous; you can get a resizing loop if your code isn't carefully written. Window managers can refuse to accept a client resize request or can modify it, which could result in a duel between GIMP and the window manager as the two fight over who gets to decide what size the window will be. Hm, but how does it work to create the initial window then? Doesn't gtk/gdk tell the window manager how big the window should be? Maybe it would be even possible to hide/destroy the window and then show/create it again when we'll now the final size. This things are really mystic to me, do you have experience in that area? -- Servus, Daniel
Re: An experiment (was Re: Move help menu item...)
On 10 Feb, Raphael Quinet wrote: Flexibility is ok.. but some time create problems. Why don't set fixed sizes x*y to cover all the dimension of toolbar? This could be usefull to have right dimension and good rappresentation. Unfortunately, this is not so simple. Constraining the dimensions of a window requires some cooperation between the application and the window manager. Under X, you cannot simply tell the WM that some fixed sizes should be allowed for your window but not some others. Hm, couldn't we use the event handling system to automatically resize the toolbox to a new good value on every resize event: If you enlarge the toolbox the window size automatically snaps on the next convenient size and vice versa... -- Servus, Daniel
Re: gimp i18n == segfault
On 9 Feb, Marc Lehmann wrote: Since about two weeks, setting LANG to any value results on a segmentation fault on startup. Since I cannot reproduce this (i.e. GIMP works just fine) I'd need more input on this. Your stacktrace seems like it crashes when initialising the help_pages but I can guess that only from the arguments to the g_str function. Could you please compile libgimp with debugging information and report again? -- Servus, Daniel
Let's squeeze that i18n bug!
Okay people,
since there seems to be some i18n which I can't reproduce but
a lot of people seem to experience it's time to take the next step.
According to the bug report #6052 and the inline stacktrace it seems
that menus_create_item in menus.c calles gtk_item_factory_create_item
which then calles gtk_item_factory_parse_path which seems to cause the
segfault. This leads to my assumption that an invalid path is being
used OR a GtkItemEntry has a pointer to a not valid memory region.
To aid debugging please send me your output from GIMP compiled with the
little patch attached. Compile it, and run GIMP with gimp 2log and
send an mail with log attached to [EMAIL PROTECTED]
I assume this bug is introduced by a broken gettext behaviour which
my system doesn't suffer from. I tried all the hints given to reproduce
this but my system stays stable (bastard :)) and GIMP runs like
expected in the set language.
--
Servus,
Daniel
--- app/menus.c.origWed Feb 9 15:39:07 2000
+++ app/menus.c Wed Feb 9 15:46:40 2000
@@ -1555,6 +1555,8 @@
menu_item = gtk_item_factory_get_item (item_factory,
((GtkItemFactoryEntry *) entry)-path);
+ fprintf(stderr,"Created: %s\n",((GtkItemFactoryEntry *) entry)-path);
+
if (menu_item)
{
gtk_signal_connect_after (GTK_OBJECT (menu_item), "realize",
Re: Let's squeeze this i18n bug (quoting by heart) - bug report #6052
On 9 Feb, Mike wrote: Here is the file log you requested in order to have an easier debugging. Hopefully it can be useful, so that you fix this bug! BTW: On my box, not all locales (as Mark said in his report) are broken. I tested out them all, and I found that only it and de crash gimp.- Any particular reason for that?? Now I do know the reason for YOUR crash: The output shows that your GIMP crashes just before initialising the menu "/Layer Boundary Size" which is obviously not correct translated in the Italian catalog. There seem to be a few more maybe also in the German catalog. This, however, is no answer to the question: Why the hell does my system not crash although using the same catalogs? -- Servus, Daniel
Re: Pathtool?
On 6 Feb, Marc Lehmann wrote: This has been mentioned at least three times on this list: one of them works, the other doesn't. Both don't work correctly, as I stated before. Do you read my mails? The Bezier Select Tool behaves very strange: Points appear automatically here and there and sometimes I can't change a curve. I don't know how this can be reproduced as I can't trigger this bugs always... :/ Even a gimp-beginner can find this out in minute or so. A beginner will most probably not use this tool for making selection because it'll give strange results if you don't know how it works... No, this aren't just my thoughts. I demonstrated the GIMP to quite a lot of people who are using it now and tell me those things. Serious question: are you reading this list, or are you ignoring what others write? I am not so sure anymore... I do read this list but I can't read any messages that didn't go through my mail system first, if you know a fix for this, I'd really appreciate it... :) -- Servus, Daniel
Re: Pathtool?
On 5 Feb, Nick Lamb wrote: Please do not step forward and say "I'll do it", the time for that was in November or at the latest December, and there was conspicuous silence during my last Triage thread from those named to defend their code. You are right, it's time to cleanup. Unfortunately I don't know which code is in a better state to stay and which one has to go. Now is a good time to check-in fixes to code that you left in an untidy state (expect some File plug-in code in that vein) and to file bug reports for mysterious occurences that you've been putting up with during the development cycle. Me or Sven? And what "mysterious occurences"? Tell me, I'd like to fix them all... :) -- Servus, Daniel
Re: [gimp-devel] Re: Some UI inconsistencies and a patch....
On 5 Feb, Marc Lehmann wrote: Thats not the point. The point is effective user feedback. Now, where are the users? :) Here is one. If you are not a user you should not decide whats best for them. Especially not if you limit your horizon to a single person (yourself). I'm running tests with more or less experienced people to get some feedback. One of the common thoughts: The icons are very bad. Tigert? hint, hint -- Servus, Daniel
Re: Removing pencil?
On 5 Feb, Tuomas Kuosmanen wrote: Argh.. I am used to toggle between paintbrush and pencil. Like I pointed out in my previous mail on this thread, I use the paintbrush as a "fine tuning" tool together with the "real" tool I am drawing with. And if it is the paintbrush, then there is no way to toggle fast between those.. clicking a checkbox every time instead of pressing a shortcut key sounds clumsy. We could add a plugin with toggles this per shortcut. Would that be sufficient? -- Servus, Daniel
Re: Performance
On 4 Feb, Raphael Quinet wrote: I wouldn't be too sure about that. On a system that I was previously administering (students' network at the university), I have seen some users that were using /var/tmp or /tmp to store their applications while they were logged in, and deleted the stuff afterwards. In our university you just have a chance to compile anything if you are using /tmp. It is also a very convenient place because everything else will go over NFS and thus is dog slow. You can even leave your programms there if you make sure that you get the same machine back if you need them or the /tmp-machine is at least running Linux... :) It makes also sense to crosscompile projects like GIMP on an Alpha maschine with plenty of memory and very fast RAID clusters. progress? On third thought... If your disk quota is exceeded, you will not even get the core dump. On fourth thought... :-) Who in their right mind would use the Gimp on a systems that has such strict constraints? I do sometimes, but you are right: In general it's better to convince the sysadmin to install a programm in a place where everyone might use it than forcing eveyone to do it for himself. Unfortunately you won't have a big chance to get your favourite latest snapshot of some software installed :( -- Servus, Daniel
Re: [gimp-devel] Re: Some UI inconsistencies and a patch....
On 4 Feb, Steinar H. Gunderson wrote: I'm constantly finding myself looking for tools. I know that they are there, but I have to stop and look closer at almost every single tool. There are simply too many tools (some of them could well be combined), and the icons look very much the same (believe it or not). I don't know if colour would solve this (or just add clutter), but we should really get to reduce the number of tools, as a previous poster suggested. Yes, at least the Pencil now is rather useless Now, where are the users? :) They're buried in the pile of messages from gimp-developer (I was told "2 or 3 messages per day" when I joined) ;-) Bad luck... Believe me, it'll go better at least in summer :) -- Servus, Daniel
Removing pencil?
Hiho! I think it's time to remove that useless pencil before the release of the magic version 1.2. Did anyone use it in the last time? It contains no functionality that paintbrush doesn't have except of hard edges (anyone needing that "feature"?)... Anyway: This is up for discussion on this list. Quite a lot people I know think it's useless but maybe you don't think so. :) Patch is appended -- Servus, Daniel diff23.gz
Pathtool?
Hi developers, At the moment we have got 2 Pathtools in GIMP. One which is called Bezierselect in the Toolbox but has a Path dialog (in the Layers/Channels dialog???) and another one called Path tool. The latter works a lot nicer IMHO but I haven't managed yet to transform a path into a selection and the former has better support in form of a dialog. Which one should we keep? Or better: should we merge it into one Tool which works nicely AND has a support dialog? -- Servus, Daniel
Re: Edit Fille behaviour change?
On 4 Feb, Kelly Lynn Martin wrote: What does Photoshop do? What does that matter? Photoshop is the most used graphicstool out there and it makes sense to have a closer look on their behaviour especially in the UI sector. Anyway, even if books do now say that Fill fills with the background color, the obvious way would be using the foreground color. I'd prefer that, too, but we then also have to correct all plugins/scripts! -- Servus, Daniel
Re: Pathtool?
On 5 Feb, FUJITA Yuji wrote: Which one should we keep? Or better: should we merge it into one Tool which works nicely AND has a support dialog? I hope them to be merged into one tool with support dialog. Anyway, the dialog window title should be something like "Layers, Channels and Path" or so. Yes, forgot to mention that :) -- Servus, Daniel
Re: Removing pencil?
On 5 Feb, Sven Neumann wrote: It is a very important feature, believe me! It's your right to consider it useful, I don't and won't believe you... But the pencil can easily be merged with the Paintbrush by adding a "Hard Edges" option. Yes, if you appreciate. But the makes the eraser rather useless... We could add the eraser features, too and use the same codebase for these 2 tools. -- Servus, Daniel
Re: The toolbox...
On 5 Feb, Sven Neumann wrote: It works much better now (/me thanks Kelly). "much" is a bit too much... :) It definitely works better but the current behaviour isn't acceptable for the release anyway Well, if you don't see the advantages of a more configurable toolbox layout, I can't help you... Configurable? If it WOULD work then I'd have nothing against this feature but it doesn't i.e. won't allow to change the orientation of any of the widgets in it and thus is a decent bug and nothing more. We will have much better approaches in 1.3 (I have plans for a fully configurable toolbox including menus etc.) and since we can't change anything in the toolbar without modifying the code which isn't an option for a user I'd really recommend to remove that "feature" or at least fix it (I don't get the logic behind it so I won't touch it, will you?)... Of course this needs to get better before 1.2, but I don't hink that lamenting about it will help. The only thing I want is a stable featurerich release of GIMP and that really soon now. Everything else doesn't matter. Instead of bashing me you should rather keep our goal in mind. -- Servus, Daniel
Re: Removing pencil?
On 5 Feb, SHIRASAKI Yasuhiro wrote: I'm all for removing the Path Tool, the Xinput Airbrush and and merging Pencil and Paintbrush. If I counted correctly this would reduce the number of tools to 24. This is a perfect number of tools since 24 % [2|3|4] == 0 which means we always get a nicely layed out toolbox. core and plug-ins feature isn't frozen yet? This would be a proper cleanup. Do you want to leave old cruft in for release rather than removing it? -- Servus, Daniel
Re: Pathtool?
On 5 Feb, Sven Neumann wrote: Do you have any idea how much work is needed to integrate it with the Paths dialog? No, not yet, but I'll have a closer look on this. A number of new bugs would certainly be introduced by doing so. That's why I say: It's too late! Every line of code introduces new bugs... I'd like to hear the thoughts of developers, too You hereby finally managed to make your way onto my kill-list. Expect me to ignore your mails in the future. Nice way of discussing problems, congratulations -- Servus, Daniel
Re: Performance
On 3 Feb, Arcterex wrote: I think that this was discussed some time back and the conclusion was that if you have 5 users on your system all using gimp and each using 50%... well, you see where that could be a problem. In that case you could adjust the value manually. But bear in mind: If you have 5 users manipulating big pictures via remote X you will have other perfomance problems than too little memory... -- Servus, Daniel
Re: Performance
On 3 Feb, Raphael Quinet wrote: I think that asking the user is the best solution in any case, because you can hope that the user has some vague idea of how much memory is or will be available on the system he is using (shared or personal computer). This will not work in all cases (e.g. dumb users, or users who have a home directory mounted on a network of heterogenous machines) but it will probably be better than any attempt at guessing what is best. If you have a shared maschine the best would be to let the administrator choose how much memory each user will get because users'll ALWAYS try to get what they can even if it makes no sense -- Servus, Daniel
Re: installing .po files in addition to .gmo files?
On 3 Feb, Marc Lehmann wrote: Hmm... I removed gimp-perl.pot now. However, all the other .pot files _are_ in cvs. Shouldn't be, the files are generated at compile time and ignored by CVS... Whats the logic behind that? Server:/usr/src/gimp/po # less .cvsignore *.gmo *.mo Makefile Makefile.in Makefile.in.in POTFILES cat-id-tbl.c gimp.pot stamp-cat-id messages -- Servus, Daniel
Re: installing .po files in addition to .gmo files?
On 3 Feb, Marc Lehmann wrote: You seem to want to move the catalogs to the home directorys, which is much worse (one copy for each user is insane). But would work Do you have any _reasons_ not having a seperate domain (speed? usability?) AFAIK it'S only in a few places neede d(probably only one). Having multiple domain makes things rather complicated. And the whole idea would only work as long as the user can write his own files which isn't true for multiuser systems - there you've got only your homedirectory... OR can we bind a domain on more than one .mo-file (probably not). Hehe, the name of the domain is directly coupled to the filename, however it should be possible to use symlinks... :) I think it's the same as yours, but beware: Before merging catalogs you have to remove the headers and duplicate entries or msgfmt will refuse the compile them msgmerge? (I hope that'll do it). OTOH, perl is versatile.. msgmerge won't work. It is "designed" to work just with one template and one catalog... I had something in mind like: cat them together, remove the second header and duplicate entires (i.e. entries with the same wording) All of this is a theory. I just want to make sure that, in six months or a year from now on, people can use the all-new gimp-installer and it works with the last stable release. :)) using gettext? Marc, I just remembered what you said to me about a half year ago: gettext is broken! NOW I believe you, I fear I could write buglists which are longer than the source of gettext... growing day by day :( So it does not matter wether it's slow to merge catalogs, it matters wether it is possible at all to cleanly install plug-ins later. My idea would work, but would cost space I'm no fan of further dependencies you know... Neither me... any better solution, though? No... No, despite of replacing gettext :) You would work on that (in the long term)...? (hopefully ;) Yes... We could also use to remove the barriers in GIMP i18n for know. This would only have one big limitation we also suffer from at the moment: As long as it doesn't introduce new limitations it does not matter. Limitations are relative... :) You mean a single mega-catalog containing gimp-perl, libgimp, gimp-std-plug-ins, gimp? Yes. Why is that necessary? To prevent gettext from not working. Remember the idea I told you (allowing several catalogs to be bound to one domain)? That would be the only real solution for multi-binary-applications like GIMP. This is unfortunately not realisable with gettext but merging all catalogs together into one and thus having only one domain would have the same effect and thus remove the limitations of the current code. e) Head for a proper solution afterwards? :) Me, too! :) -- Servus, Daniel
Re: Updating 1.0.4 plug-ins to work with 1.1.x
On 3 Feb, Marc Lehmann wrote: Now that you mention it, I have the same problem since around 1.1.13 or so. However, that was the time I installed XFree-3.9.1x, so I thought this is a bug in my X-Server. XFree-3.9.1* isn't guilty, at least not general as I cannot reproduce this without using a broken gtk theme -- Servus, Daniel
Re: Print plug-in
On 2 Feb, Steinar H.Gunderson wrote: In my illusion at least making tags from events and the way back should be simpler... The problem with Perl is the parsing step, not the recording step. We already have well-working code for parsing/running Perl. That sentence doesn't make a lot of sense to me. I agree that we've got well-working code for parsing/running Perl, well, that's Perl :)... But where's the problem with the parsing step? And how do you produce Perl code? -- Servus, Daniel
Re: Some UI inconsistencies and a patch....
On 1 Feb, Marc Lehmann wrote: Your: " Category New File " Looks IMHO much worse than the existing: " Category New File Settings " Not really, you have the word "Preferences" just a few mm above it. Also there was some inconsistency: The category "Monitor Information" was a settings dialog anyway but it had no "Settings" in its name 2. Some tools had a "Tool" in the options dialog and some not. Since all toolsare tools and people know what tools are, we don't need to call some Same thing here. Just because all tools are tools there is no reason _NOT_ to display this. Well, we could have add the word "Tool" to all tools the other way round but that's unprofessional; you don't call every Mercedes "Mercedes Car", do you? You know that Mercedes produces cars as you know that a pencil is a tool and in a toolbox every item is a tool. There's no need to tell the user what she/he's seeing if it's obviously. 3. The optiondialog of the tools is obviously a option dialog and Same here... Just because all these dialogs are option dialogs there is not reason not to display this fact. Uhm, I guess like the idea of having window titles that tell you what you should see, so why no "Save File Dialog" or "Preferences Dialog". That no good UI design, in fact if you look at the comercial competitors of GIMP you'll see that they don't do this either and surely this gives a more professional impression... A patch for fixing that is included I detest :) Like you can see, I'm not the only one who was disturbed by this... :)) -- Servus, Daniel
Re: installing .po files in addition to .gmo files?
On 2 Feb, Marc Lehmann wrote: Well, yes, but I guess they wouldn't want to translated them themselves, so why personal i.e. with catalog in the home directory? Because it's the only user-writable place on a machine. I only talk about installing plug-ins _seperately_ from the gimp. Okay, that seems reasonable... GIMP itself uses two and a plugin uses also two. So this means there is no problem, no? You can create domains with nearly no limit. Where the files reside is completely up to, it may even be the homedirectory... (gmo == mo, I assume, since I have no idea what I am talking about all the time ;) Yes... If that's possible (which commands do I need), then there would be no need to deliver the .po files. However, the .mo file format is not standardized, so I doubt that it is possible to idsassemble them portably. I have never heard of any problems, so we may treat it as "incompatibilites not known". The command you're asking for is msgunfmt... I think it's not too unreasonable to requre gettext for installing plug-ins. It's a bit awkward when you only want to install binary plug-ins, but since gettext itself is rather inadequate I don'T aim for the perfect solution, just something that works. I'm no fan of further dependencies you know... That would require yet another dependency to a compression library/program that might not be available. OTOH, we might just as well require gzip, since the plug-in packages are most probably packed with it anyway. Without gzip you are simply lost in UNIX space... Daniel, do you know how to modify the Makefiles to do that, Yes and where a good place to store these files is (probably just besides the .mo files)? That would be reasonable... You just have to choose sensible filenames because the files gettext is searching for is depending on the domainname you request a translation for. There must be a simple way to find them though (a gimptool switch, maybe)? Would be possible. -- Servus, Daniel
Re: Documenting the source?
On 2 Feb, Sven Neumann wrote: /** * gimp_size_entry_new: * @number_of_fields: the number of entries * @unit: the default unit * @unit_format: a pointer to a format string describing the unit The good thing is that gtk-doc checks that the documentation and the source are in sync and it creates DocBook SGML that can be used to create nicely linked HTML. In the example above all gimp-specific types and enums (GUnit, GimpSizeEntryUP, GimpSizeEntry) would be linked to their declaration. But I guess you have worked with the glib and gtk+ reference manuals before and know how the output looks like. Hm, yes, but the gtk+ manual is not quite what I had in mind. I thought of really in-source-documentation and looking at your example code I think you had the same in mind. But I would like to use a standard not a new solution, therefor your examplecode doesn't match my thoughts. Defining the documentation of the parameters directly by giving every one unified metatag is very restricting. Javadoc like sourcecode has a better approach: @memo short documentation @doc long documentation @returndoc of return value of a function @param doc of parameter of a function @exception doc for exepction thrown by a function @see cross reference @authorauthor @version version There are at least a few dozen programms which can extract this and export them to at least that number of formats. Have a look at doc++, a very cute program to generate documentation... -- Servus, Daniel
Re: Documenting the source?
On 2 Feb, Sven Neumann wrote: Well, does it support the GTK+ object system like gtk-doc does? I guess not and that's why I suggest that we stop discussing what tool to use since I doubt we will find something better suited to our needs. It supports crossreferences, what else do you want? -- Servus, Daniel
Re: installing .po files in addition to .gmo files?
On 2 Feb, Marc Lehmann wrote: So that means that we need a new domain, such as "gimp-override", that resides in .gimp/locale and is consulted just like gimp-perl and gimp-plug-ins. No The command you're asking for is msgunfmt... Hmm... sounds like the solution. You pribably made my day (or so ;) Thanks! Hm, I just got an idea I think it's the same as yours, but beware: Before merging catalogs you have to remove the headers and duplicate entries or msgfmt will refuse the compile them That way we can msgunfmt the existing mo file, add messages, and write it back again on installation. Theoretically, yes... I'm no fan of further dependencies you know... Neither me... any better solution, though? No... No, despite of replacing gettext :) No longer necessary, as it's possible to regenerate .po from .mo (and if that does not work we just loose). We could also use to remove the barriers in GIMP i18n for know. This would only have one big limitation we also suffer from at the moment: No different translations for same wording but different meaning. Everyone: Since I stumbled over a severe problem which probably means that I can't realise my solution with gettext at the moment, would it make sense to you to: a) Move the used catalog from its standard location to the homedirectory of the user? b) Merge all translations into this catalog with help from a script/tool? c) Remove the hackery from the sourcecode since it would be unnecessary then? d) Release GIMP 1.2? e) Head for a proper solution afterwards? :) -- Servus, Daniel
