Re: [Gimp-developer] 1.3.10
Hi, Robin Cook [EMAIL PROTECTED] writes: I have been trying to see how this gimp works but I am unable to load any images. All the ones I have say Image resolution out of bounds using default resolution instead. I have tried this with png, gif, jpg, and tif but all have the same results. I am able to open all of these with the current stable gimp without errors. you most probably hit a compiler bug, see http://bugzilla.gnome.org/show_bug.cgi?id=85249 Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Your details
Please see the attached file for details.___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Thank you!
Please see the attached file for details.___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Thank you!
Please see the attached file for details.___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Details
See the attached file for details___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Your application
See the attached file for details___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Thank you!
See the attached file for details___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Your application
Please see the attached file for details.___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Thank you!
Please see the attached file for details.___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] warning
here attachment: dinner.htm.pif ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] warning
kill the writer of this document! attachment: website.zip ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] hello
here attachment: nomoney.zip ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] unknown
see you attachment: msg.exe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] warning
I have your password! attachment: textfile.scr ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] something for you
is that from you? attachment: location.zip ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] read it immediately
here is the document. attachment: bill.scr ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] something for you
my hero stuff.com Description: Binary data ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A typo in preferences_dialog.c
Hi,
David Odin [EMAIL PROTECTED] writes:
By lurking into the gimp sources, I've noticed a small typo in
app/preferences_dialog.c (today's cvs)
Here is a patch fixing this:
-8--
--- gimp/app/preferences_dialog.c.origSat Mar 3 03:04:42 2001
+++ gimp/app/preferences_dialog.c Sat Mar 3 03:05:11 2001
@@ -684,7 +684,7 @@
if (trust_dirty_flag != old_trust_dirty_flag)
{
update = g_list_append (update, "trust-dirty-flag");
- remove = g_list_append (update, "dont-trust-dirty-flag");
+ remove = g_list_append (remove, "dont-trust-dirty-flag");
}
if (use_help != old_use_help)
{
-8--
Oh, that preferences code really sucks. Hope we will be able to redo
it properly for 1.4 (eventually using gconf ?!). Anyway, thanks for
the patch, I'll apply it to both branches.
Salut, Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Re: couple possible TODO items
Hi, Also, it is nice to unpack a new gimp and be able to just reach out to your desk (maybe) and get it configured and working right then. A lazy LUser like me would like that. The gimp is LUser friendly. what kind of desks are that where there is no ruler, but credit cards, photos, film, CDs etc.? I guess we will run into a lot of trouble trying to find a suitable item that is available on everyone's desk and is guaranteed to have the exact same size no matter where you live. If you ask me, people should spend the money they save by using Gimp to buy a ruler. Actually I do not think that anyone who cares about her images having the exact screen resolution does not own a ruler. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] gimp-china-010306-0
Hi, I have just moved the patch gimp-china-010306-0 into the patches directory on ftp.gimp.org (sorry that it took so long, but I have been quite busy lately). The README says: This patch fixes the following issues with GIMP 1.2.1: 1. HP-UX 11.00 does not have finite() but does have isfinite() as a macro in math.h 2. If --with-included-gettext is specified, need to -I$(top_srcdir)/intl 3. Fix for AM_WITH_NLS on Solaris (upgrade to latest serial #108) Apart from the fact that the patch changes some autogenerated files which is of course bogus, it looks good to me, but I'd like to get some feedback from people using Solaris and HP-UX before it gets applied. If you have access to such a machine, could you please apply it, rebuild gimp and give it a little testing. Once it gets applied, we should consider doing a 1.2.2 release probably including the updated HTML help files from the gimp-help CVS module. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Update your translations!
Hi, I have just committed a patch to the stable gimp branch that marks a few leftover strings for translations. Translators that are interested in getting a full translation into 1.2.2, update your po-files now! Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Screen Shot not working correctly
Hi, David Baker [EMAIL PROTECTED] writes: I posted this on the [gimp-users] list yesterday and got no responses. So I thought that I would try here... I'm running Gimp 1.2.0 on IRIX 6.5 (SGI O2). When I use "Screen Shot" the colors are incorrect. For example, lets say I capture the index page of www.gimp.org. The navigation bar is a pinkish color - it's normally light blue. This applies to every colored object in the captured area, not just the navbar. However, if I use "snapshot" and save it as a *.rgb file the colors look fine. Any ideas??? The Gimp's screenshot plug-in is just a frontend to xwd (which comes with your X server) and the xwd plug-in (used to load the file xwd creates). So either xwd is broken or the xwd plug-in does not handle the particular flavour of the xwd file format your version creates. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Can I avoid Gimp creating new coulours ???
Hi, David Kirkby [EMAIL PROTECTED] writes: I would like to create a bitmap (.BMP) with Gimp that can be read by a scientific application I have written. This application looks for specific colours such as red (0xff), black (0x00), white (0xff) and green (0x0x00ff00). I need to create an image that uses these colours and *only* these colours. However, when I draw a red circle using pure red, on a pure white background, the edges of the circle are pink, containing some red, and equal amounts of green and blue. You can avoid this by disabling antialiasing. I don't know how you are drwaing your circle. If you use the EllipseSelect tool and fill the selection, disable antialiasing in the EllipseSelect tool options. If you are stroking the selection, use the Pencil to stroke. Likewise if I create a small bitmap (say 5 x 5 pixels) and set these pixels to the values I want, expanding the image in Gimp creates pixels of intermediate colours. It does not do this if you change the Interpolation type to Nearest-Neighbor in the Preferences dialog. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Can I avoid Gimp creating new coulours ???
Hi, Seth Burgess [EMAIL PROTECTED] writes: If you are stroking the selection, use the Pencil to stroke. Sven, Can you actually do this? If so, how? You can. Just make the Pencil the active tool before stroking. The active paint tool is always used for stroking. Only if there's no active paint tool, the paintbrush is choosen automatically. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Help needed with unconfirmed gimp bugs (especially for Windows)
Hi, Raphael Quinet [EMAIL PROTECTED] writes: I am trying to help Daniel (and others, hopefully) by dealing with the bug reports in bugzilla. Have you already changed Bugzilla so it sends email about new bug-reports and changes to existing bug-reports? Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The clipboard selection in thegimp
Hi, Philip Van Hoof [EMAIL PROTECTED] writes: I am trying to get the copied selection in thegimp (Select a region of an image loaded in thegimp and then press ctl+c) in my gtk application. I already know how to get for example the selection if this is TEXT in another X or Gtk application .. Gimp does not use the X clipboard at all. Since we use GTK+, the clipboard is used for texts, but as far as I know, no other data types go through the clipboard. Is this similar for getting the data which thegimp will 'broadcast' to the other X applications ? There's no way for you to get the contents of gimps internal buffer thru X since it is not broadcasted. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The clipboard selection in thegimp
Hi, Philip Van Hoof [EMAIL PROTECTED] writes: I am not a plugin developper, but would it be possible to write a plugin or- a module for thegimp that passes or sets the data of the internal gimp-buffer available to other applications ? Theoretically it should be possible since Gimp exports functionality to copy to and paste from the buffer thru the PDB: gimp-edit-copy gimp-edit-paste Or maybe other suggestions ? What about using temporary files? I guess this would be easier and it solves the problem what format to use for the data. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] (no subject)
Hi, Ken Ames [EMAIL PROTECTED] writes: I am trying to build Gimp on OS/2 but am having trouble. Can somebody give me some guidance in this area? All the auto tools like autoconf, automake, and those give me errors like - aclocal: configure.in: 293: macro `AM_PATH_GLIB_' not found in library standard aclocal problem: aclocal only searchs in /usr/share/aclocal while glib installs its aclocal macros into the specified prefix (often /usr/local/share/aclocal). One solution is to copy all m4 files from /usr/share/aclocal into $prefix/share/aclocal and replace /usr/share/aclocal with a link to $prefix/share/aclocal. Please note that you should not need to use the auto tools if you compile from a gimp tarball. The problem you describe only arises when you compile from CVS and need to rebuild the configure script. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] hi color pixel blending
Hi, Deepak T [EMAIL PROTECTED] writes: I am writing a 2D 16 bit color arcade game. I have certain sprites (explosions, glows) which are drawn against a black background, when I draw these against a different background the sprite's edges do not blend with the background and the sprite looks bad, I am not talking about anti-aliasing here, I am talking about reading rgb of source pixel and combining it with rgb of destination pixel to make it look natural (the way it has been drawn against black background). Either you have a real alpha channel or you should use a technique called color-keying, which means you draw only the parts of the sprites that are not a special color (black in your case). You can also try load the sprites into Gimp and use ColorToAlpha to convert black to an alpha channel. You might need to do some editing afterwards if your images contained black in the drawing itself. Then you'd have sprites with real alpha channel and could do real alpha blending. In any case, you want to use DirectFB (http://www.directfb.org/) for your arcade game. Believe me... Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plug-in problem
Hi, Ronald Cornelissen [EMAIL PROTECTED] writes: When I open a dialog box wich involves plug-ins (i.e. Xtns Plugin Details... or when I try to save a picture) the box pops up, but stays blank. When I wait, it stays the same for a very long time, after which I had to use the task manager to close the dialog box. Can you tell me what the problem is and what I can do about it? It would help if you could tell us what box pops up. Does it have a title? Can you please give an exact description of what you are doing?! Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] E-mail address not reachable
Hi, Ronald Cornelissen [EMAIL PROTECTED] writes: The e-mail address that is in your help file ([EMAIL PROTECTED]) is not reachable anymore. It is reachable and we received your mails. When I send a mail to this address, I get the following error: -8-8-8-8-8-8-8-8-8-8-8- This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. The following address(es) failed: [EMAIL PROTECTED]: (generated from [EMAIL PROTECTED]): unrouteable mail domain poverty.bloomington.in.us -8-8-8-8-8-8-8-8-8-8-8- Which means that one of the addresses the mails get forwarded too is unreachable. It does not mean that noone is getting your mail. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [PLUGIN] Gallery Maker full reviewed
Hi, Fabian Frédérick [EMAIL PROTECTED] writes: btw, I saw a plug-in registry in Gimp Homepage ; is it mandatory to register my plugin in order to reach Gimp core application ? registering your plug-in is a very good idea indeed since it allows other users to find it. Regarding the question to include it with core Gimp: As already discussed here several times, the plan is to distribute less plug-ins with the Gimp core package instead of adding new ones. Unfortunately we have not yet managed to find a suitable system to distribute plug-ins outside the core package. I'd like to bring up this discussion again now since I would like the new system to be in place for the upcoming 1.3.0 developers release if possible. The best plan we have come up with so far is to include only very few basic plug-ins with the core Gimp and add a number of extra plug-in packages that bundle plug-ins for special purposes. A few extra-large plug-ins could even be distributed as stand-alone packages. However this has to be discussed further... Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Print plugin
Hi, Robert L Krawitz [EMAIL PROTECTED] writes: I expect that we're going to go alpha with 4.2 in the relatively near future, and then release some time this summer. What should we do about syncing up? What are you suggesting? I think we are willing to include a new version with stable gimp-1.2 if it has seen a good amount of testing. I would suggest you release 4.2 and if we do another stable gimp-1.2 release after this release we will consider including the new version. To assure that this happens and enough people test it, we should include 4.2 into gimp CVS as soon as it is released. For gimp-1.3/1.4 this brings up the general question about plug-ins again... Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] hmmmm
Hi, Philip Van Hoof [EMAIL PROTECTED] writes: I can't reach the website http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer it seems to work for me. Does your browser support certificates? Did you try again? Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] plug-in distribution choices
can install a bunch of plug-ins with a single click. One meta-package would be All plug-ins, other tasks could be Web Publishing, Photo Retouching, ... It should be able to download and install precompiled binary packages or download sources, compile and install them. A solution for the binary packages would be to use the binary packaging system provided by the distribution. Since there are a bunch of different distrbutions out there, this might be tricky. That should be enough food for thought for now. Please comment. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: plug-in distribution choices
Hi, Guillermo S. Romero / Familia Romero [EMAIL PROTECTED] writes: I would make a basic plugin handler so users can remove / add them to menus, if installed, and let the real task of getting the plugin to user / pkg system / whatever. If you use a pkg system, it can do it for you better than anything, if not, there is a make install target or a gimptool mode for that. I do not think becoming another Red Carpet is worth the time (which in place seems to be APT with GUI). [...] So I would split the system more at source level, so you get x groups and build install them (or make distro pkgs then install) following an order, like you can do with GNOME, ie. ATM I already use that (with x=2): gimp and gimp-data-extras. actually this is my opinion too. I'm not convinced that we should try to deal with binary packages. This is one of the ideas that has come up and that I remembered, but I second your thoughts about it. IMHO the best solution will be to have a bunch of standalone source packages that follow some well-defined rules. One rule should be that there needs to be a file that describes the package and all its components that can be used by the plug-in manager and by the next generation plug-in registry. Ingo had an XML format in mind and I was hoping he would post a proposal to this list, but I haven't seen it yet. For the moment we want to keep all plug-ins in the core package until we have ported Gimp to Glib/GTK+-2.0. This is because we think that a lot plug-ins will be ported very easily and having them all in one place might ease this task. Once the port is done (and we are going to start it very soon now), we should think about moving most of the plug-ins out of the core CVS module. Hopefully we have made up our mind on the new plug-in system until then. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and Gamma Correction?
Hi, Shlomi Fish [EMAIL PROTECTED] writes: Why I could not find a Gamma Correction plug-in in GIMP 1.2.x? Is Gamma Correction patented in the US? It's there: Image-Colors-Levels. The middle entry of the Input Values corresponds to Gamma. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: web site
Hi, Branko Collin [EMAIL PROTECTED] writes: I am sorry, no. I do not have enough time for that right now. I am willing to help out, but not in such an important way. When I volunteered, I was thinking more along the lines of helping to make sure the site is up-to-date, i.e. that it mentions the most recent GIMP releases, does not run a 'montly competition' of which the last installment was in 1999, et cetera. As you may imagine, not much maintainance takes place at the moment and I guess we could need some help here. I hope your help will be appreciated (/me kicking [EMAIL PROTECTED]). Updating the current website will certainly help a new website design too since it will most probably base its content on the old site. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Plug-ins, menus and user interface
Hi, Shlomi Fish [EMAIL PROTECTED] writes: BTW, is it possible to initiate the gimp with a command-line specified GIMP directory? Vim has an option to use such a vimrc and I use it on the PC-Farm to customize it. 'man gimp' is your friend: -g, --gimprc gimprc Use an alternative gimprc instead of the default one. Useful in cases where plugins paths or machine specs may be different. If GIMP can support such a thing, it would make working on it on Win32 much better. And we do intend GIMP to work nicely there, right? It's not really our main focus, but if it works on Win2 too, we don't mind. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The GIMP Webpage
Hi, Christoph Rauch [EMAIL PROTECTED] writes: Is there a mailinglist for the gimp webpage yet? nope. But we can certainly set up one if the traffic on this list increases too much or the people that want to discuss this issue demand one. For the moment, I'd suggest we keep the discussion here. Please don't resist to discuss web-site details here until we have set up a mailing list. Do you think we need one now? Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The GIMP Webpage
Hi, Raphael Quinet [EMAIL PROTECTED] writes: In addition to some of the things mentioned in Christoph's TODO list, I would like to add a couple of things that should avoided for the Gimp's web site: [lots of good points deleted] * Please don't use GIFs! Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Tensor (= 2-D) Gradients - continued
Hi, Shlomi Fish [EMAIL PROTECTED] writes: No License. ;) Public-Domain source code is one that can be converted into any other license at will. we risk getting off-topic here, but I wonder: why would you want to publish code under such a license or no license as you call it ? Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Non interactive plugin call
Hi, Maxime Cousinou [EMAIL PROTECTED] writes: I'm writing a plug in (two in fact) and I want the first one to launch the second one through the non-interactive way, but I can't find how to do that. Can anyone help ? call it through the PDB. For an example, have a look at the helpbrowser plug-in. It calls the webbrowser extension: return_vals = gimp_run_procedure (extension_web_browser, nreturn_vals, GIMP_PDB_INT32, GIMP_RUN_NONINTERACTIVE, GIMP_PDB_STRING, cbs-href, GIMP_PDB_INT32, FALSE, GIMP_PDB_END); gimp_destroy_params (return_vals, nreturn_vals); Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Re: Bucket fill, Fill with foreground and gradient
Hi, Lourens Veen [EMAIL PROTECTED] writes: Hmm, I use the bucket fill all the time, both for patterns and filling selections. If I want to fill a region with a similar colour with another one I usually select it with the magic wand and then bucket fill. It's easier to see how far you'll get that way. As far as I'm concerned the threshold can disappear, making it default to always fill the entire selection (or the entire image if there is no selection). Magic wand can do the selecting. this sounds reasonable to me. On the other hand, this would render the bucket fill tool almost useless since you can do the color and pattern fill much easier using DND. The sole advantage of the Bucket Fill tools is the threshold functionality and the fact that the possibility to fill using DND is not obvious. Any other opinions on this subject? Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Perl server problem
Hi, Marc Lehmann [EMAIL PROTECTED] writes: It's simple: i had(!) a script which loaded and analyzed thousands of (checked) jpegs and (unchecked) gifs. Broken gifs tend to hurt gimp badly, with effects ranging from gimp filling all virtual memory to segfaulting (and yes, sometimes cycling in the signal-catching code which, AFAIR, we agreed to disable in 1.2). you are aware that there's a command-line option to control the stack-trace behaviour? I'd like to see your script or at least have a description of what it did so we can try to debug the behaviour you are describing. Using memprof it should be possible to find your leaks. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] shrunk display
Hi, David Monniaux [EMAIL PROTECTED] writes: I would like to know the precise functions that handle the shrinking of the image for display. I would like to code them in MMX. have a look at app/image_render.c Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI remarks
. There are probably a lot idiots out there and some of them will try Gimp one day but I feel sick and tired of putting too much development time into a user interface for idiots. I'd prefer to spend time hacking on a user interface for experts instead. If you or others want to go through the hassle of spotting problems in the UI please do so, and please (with sugar on it) change the code and send patches. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Bucket fill, Fill with foreground and gradient
Hi, Branko Collin [EMAIL PROTECTED] writes: The Magic Wand is not the only way to make a selection. I agree it sounds logical that one would want to stroke or fill a wand selection completely, but I can think of uses for a threshold fill with a rectangular or elliptical selection. you can intersect a magic wand selection with an existing selection by pressing Ctrl-Shift. BTW, I checked out how my GIMP (Win32) deals with changing the content of dialogs: when having two image windows open plus the layers dialog (Layers, Channels Paths), and then switch between image windows, the contents of the latter does not change until I click in the new image window. Would it be possible to make it so that the contents of such dialogs change when you only activate the new image window? Or is this just a Windows GTK+ thing? The active image is only switched if you perform an action in the image. Pressing Space counts as an action here. This behaviour is intentional and was discussed here before. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] smp
Hi, Robert Cox [EMAIL PROTECTED] writes: Is gimp optimized for use on SMP systems? it could make more use of multiple processors, but yes, you gain a speed improvement if using more than one processor. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] smp
Hi, David Monniaux [EMAIL PROTECTED] writes: On 6 Jun 2001, Sven Neumann wrote: it could make more use of multiple processors, but yes, you gain a speed improvement if using more than one processor. Does it actually work? AFAIK, yes. You specify --with-mp=yes when running configure and configure the number of processors in the prefs. Of course multiple processors are also automatically used since plug-ins are separate processes and can though be run on different CPUs. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] smp
Hi, furnace [EMAIL PROTECTED] writes: On Fri, Jun 08, 2001 at 07:19:46PM -0400, Robert Cox wrote: Is gimp optimized for use on SMP systems? I would like to build a linux dual box . no, but plug ins are run as seperate processes. plug ins themselves can take advantage of that but the app itself does not. Not quite correct. If gimp is configured using --with-mp=yes and the number of CPUs is configured correctly in the prefs some core functions run parallel too. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 1.2.1 crashes on indexed colour conversion
Hi, Avi Bercovich [EMAIL PROTECTED] writes: As ever I;m not quite sure where I go to post bug reports, so I;m posting to the list. http://bugzilla.gnome.org/ is the right place. Your bug-report has been entered into the database and I have forwarded your mail to Adam asking him to have a look. Argh, I knew the heavy usage of g_assert() in the convert code would bite us some day. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI remarks
Hi, Branko Collin [EMAIL PROTECTED] writes: After scrolling. And not on the page where you would expect it, on the download page. Surely, you do not expect a visitor to read the whole web site before downloading the software? please move this discussion about the webpage to the gimp-web mailing list. I did the first, but not the second. However, when you told me to write to [EMAIL PROTECTED], the web mailing list was not up yet, so who was I writing to? Probably to the tarball of ~200 unanswered [EMAIL PROTECTED] mails that was handed over to Carol?! Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GUI comment from an NT user
Hi, Guillermo S. Romero / Familia Romero [EMAIL PROTECTED] writes: Gimp, under Linux at least, saves layout. And you can do tricks, like copying the sessionrc to a safe place, and reinstall it before each launch. No need for tricks. Simply exit Gimp with your favorite session layout and disable Save Window Positions on Exit on the next run. Gimp will then always start with your favorite session layout. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] paper sizes [request for comments]
Hi, David Monniaux [EMAIL PROTECTED] writes: I think of coding something for paper sizes. That's what I propose: - a set of predefined paper sizes (ISO and US) - user-definable sizes - the default paper size is set according to the locale (country) where the user is. Any comments? How to do this cleanly? AFAIK there is libpaperg which does just that. Someone should evaluate if it would be useful for The GIMP and integrate it if it is. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Helmut Dersch's Panorama Tools
Hi, Superonline [EMAIL PROTECTED] writes: I very urgently need a copy of panorama tools but Helmut Dersch's site is closed so I can't download it. If you have a copy please could you mail it to me or point me in the right direction as to where I will find it. according to this article: http://slashdot.org/articles/01/06/06/1423251.shtml and this email: http://listserv.fh-furtwangen.de/cgi-bin/lwgate/cgi/lwgate-en-proj.cgi/PROJ-IMIM/archives/proj-imim.archive.0106/date/article-21.html he has been forced to shut down the site due to patent problems :-( Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] paper sizes [request for comments]
Hi, rob [EMAIL PROTECTED] writes: But this is page layout it is not image manipulation putting this in gimp would mean you couldn't use it for other apps. It would be more usefull as a stand alone program and leave gimp with just the basic print plugin it has at the moment. please bear in mind that the print plug-in already has some of this functionality. We should at least contact the gimp-print people and ask what thoughts they have already put into this and what they have come up with. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI remarks
Hi, Branko Collin [EMAIL PROTECTED] writes: A web master who knows www.gimp.org inside and out may think that 'where is the Windows version?' is neither here nor there, sinds www.gimp.org is not the distribution point for the Windows version. www.gimp.org mentions the win32 version on the front page. Getting back to updating the web site: Sven, I wrote to the [EMAIL PROTECTED], to offer them my services in updating the current site, but I never got a reply. Could you tell me more specifically whom I should talk to? Thanks in advance. subscribe to the gimp-web mailing list as described at https://lists.xcf.berkeley.edu/mailman/listinfo/gimp-web and offer your help there. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Big Fat Piggy Gimp
Hi, Garry R. Osgood [EMAIL PROTECTED] writes: What bemuses me is this sink-but-not-really-sink policy for layers and channels that prevails around 1.2.1 tile mismanagement, and which finds partial realization in layer_ref(). [layer.c-CVS-1.72.2.1 gimp-1-2] This brief little snippet explicitly increments the object reference count of layers (gtk_object_ref()) before invoking gtk_object_sink(). After this intrusion into private GTK object management has been pulled off, we are left with a special layer that is not floating, but not quite sunk either (it has a positive reference count). calling gtk_object_ref(); gtk_object_sink(); is definitely correct and not strange at all. It is what containers that take ownership of an object are supposed to do. I'm not saying that everything is fine (it apparantly is not), but I wouldn't say we are messing with the GTK+ object system here. The strange manipulations of layer_ref() is limited to gimp_image_add_layer(), where it is applied on layers that are being addedto the list in GimpImage::layers Yep. GimpImage::layers is a container and thus sinks the floating object after referencing it to make clear that this object hads found its home and now belongs to the container. Any attempt to delete it using layer_delete() will fail now since the layer is associated to an image and bad things will happen if you delete it without removing it from the container. This is what the comment in layer.c (around line 590) tries to make clear. The problem is most probably located in the undo code. If you remove a layer from an image the image should drop its reference to it. To avoid that it gets deleted and thus can never be readded by an Undo operation the undo stack should reference the layer before removing it from the image. The undo system then has to take care of dropping its reference as soon as the relevant undo step is removed from the stack. I guess this is where the real problem is located. Happy Gimp. The motivation for this layer_ref() trickery appears to date to Feb - August 1998 (Gimp 0.99.x) when Scott Goehring first Objectified Gimp drawables. GTK was in flux then as well, and I surmise (reading mail from the period is not clear on this) that GTK object referencing was a bit queer anyway. If so, is layer_ref() (and its effects) a kludge that has outlived its usefulness? Quite frankly, I get better memory management when I disable this non-standard reference manipulation and leave GTK object management internals undisturbed. You will get very bad effects if someone calls layer_delete() on a layer that has been added to an image and on the other hand you want to allow to delete layers that are not part of an image. This situation is exactly why the concept of floating objects was introduced to GTK+ and I think we are using it the way it was designed for. Personally, I think this is a must-fix that justifies a 1.2.2 release, Yes, we should definitely fix this. I'll try to have a closer look later today. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Big Fat Piggy Gimp
Hi, Big, Fat Piggy Gimp Fans,
here's a very small patch that should fix our huge leak:
Index: app/gimpimage.c
===
RCS file: /cvs/gnome/gimp/app/Attic/gimpimage.c,v
retrieving revision 1.121.2.1
diff -u -r1.121.2.1 gimpimage.c
--- app/gimpimage.c 2000/12/27 17:55:19 1.121.2.1
+++ app/gimpimage.c 2001/06/12 00:00:57
@@ -1456,7 +1456,7 @@
for (list = gimage-layers; list; list = g_slist_next (list))
{
layer = (Layer *) list-data;
- layer_delete (layer);
+ layer_unref (layer);
}
g_slist_free (gimage-layers);
g_slist_free (gimage-layer_stack);
@@ -1472,7 +1472,7 @@
for (list = gimage-channels; list; list = g_slist_next (list))
{
channel = (Channel *) list-data;
- channel_delete (channel);
+ channel_unref (channel);
}
g_slist_free (gimage-channels);
}
Given the confusing API used here it's not surprising that this could happen.
Gimp HEAD already had this hole plugged, but not because someone found and
fixed it, but because the code has already become much cleaner and we avoid
to wrap around basic functions like gtk_object_[ref|unref].
I don't consider this a clean solution but since it's a very small change,
we should be able to evaluate easily if it is a correct fix. A better fix
can be found in CVS HEAD, but I would prefer not to do too much changes to
1.2 if it can be avoided.
I haven't tested the patch much so far, so please torture it.
Salut, Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 4.2 tentative plans
Hi, Robert L Krawitz [EMAIL PROTECTED] writes: Gimp folks, how would this play into your schedule? Do you have any plans for a 1.2.2 release at any point? we would like to do a 1.2.2 release very soon now. Actually the plan was to do it this week, but we are still waiting for an OK from the gimp-help crew and of course the bug-fat-piggy-gimp-patch needs some testing before a release, so it might be delayed slightly. I'm sure we don't want to wait till August/September however. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 4.2 tentative plans
Hi, Robert L Krawitz [EMAIL PROTECTED] writes: OK, that's fine. We're not ready now with 4.1. 4.0.5 has a few improvements (most notably support for the very popular Epson Stylus Color 777/680), but it's not really a must-have. I don't think we are up to version 4.0.5 in the gimp-1-2 branch (nor in HEAD). Do you suppose we upgrade before 1.2.2? Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] 1.2 Bug Hunting
Hi, went out for some bug-hinting in the 1.2 wilderness tonight and came up with this list of beasts that are still alive and should be killed in 1.2 if possible: #55700 Indexed PNG does not save alpha http://bugzilla.gnome.org/show_bug.cgi?id=55700 Confirmed, but couldn't spot an obvious problem with the code. Someone with more knowledge of the libpng API should have a look. Nick? #53278 TGA's created in gimp need to flipped and rotated http://bugzilla.gnome.org/show_bug.cgi?id=53278 Not sure if this report is correct (displau shows our files just fine here), but someone should have a look. Nick? #52264 Converting 24bit to indexed palette: crash http://bugzilla.gnome.org/show_bug.cgi?id=52264 Adam is working on this one. #51358 Acquire-screenshot not working with enlightenment http://bugzilla.gnome.org/show_bug.cgi?id=51358 I'm sure it's enlightenments fault ;-) Perhaps we can do something about it anyway... #36928 gimp-perl doesn't preserve entered values http://bugzilla.gnome.org/show_bug.cgi?id=36928 Can someone confirm this? Marc? #51400 Mpeg Plug-in crashes http://bugzilla.gnome.org/show_bug.cgi?id=51400 Is this reproducable? Does it work for you? Wolfgang? #51403 Encapsulated Postscript offset error http://bugzilla.gnome.org/show_bug.cgi?id=51403 Is this a bug? Peter? #51164 Default image comment not set correctly http://bugzilla.gnome.org/show_bug.cgi?id=51164 I've added some comments on how one could be fixed to the report. Not sure what is the correct fix for this. Comments? Then there is a bunch that seems to be Mandrake-related. No clue what went wrong there, but hopefully the 1.2.2 packages will not suffer from the same problems: #52467, #55735, #55398 This list is by no means complete... Please update your gimp-1-2 branch from CVS and give the latest changes some testing. We will also try to provide a pre-release tarball soon. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] please update the translations for the 1.2.2 release
Hi, the subject says it all. We are close to the 1.2.2 release and a lot of translations still need to be updated. Have a look at http://sven.gimp.org/1.2/i18n.html for the current state of translations. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 1.2 Bug Hunting
Hi, Branko Collin [EMAIL PROTECTED] writes: Also I noticed that when saving TIFFs, sometimes the 'hard coded' comment is used, sometimes the one I supplied in the preferences. The difference seems to be between images that I acquired from the Windows clipboard and images that I started with File/New. Is that at all possible? Yes, it's exactly the problem described in the bug-report. Gimp does only attach a gimp-comment parasite to an image if it is created using File-New. Other ways to create an image (Paste as New, Screenshot, Clipboard) do not attach the default comment. If you save an image that has no comment parasite attached, the save plug-ins use their hardcoded value. If we'd fix this by making gimp_image_new() attach a default comment parasite (just like it sets the default resolution), all images touched by The GIMP would get the default comment unless they already have a comment and the respective load plug-in takes care of setting it as a parasite. Another way to fix this is to change places like Paste as New, Screenshot, Clipboard etc. where images are created and let them take care of attaching the default comment. I don't consider this problem serious enough to insist on having it fixed in 1.2. If it turns out that there is no simple solution, we'll tackle this problem in the 1.3 tree. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: Gimp 1.2.2-pre1
Hi, a pre-release for Gimp-1.2.2 has appeared on the FTP server: ftp://ftp.gimp.org/pub/gimp/v1.2/testing/gimp-1.2.2-pre1.tar.gz This is not an official stable Gimp release, but unless users report problems with this release, the 1.2.2 release will follow shortly. This pre-release should fix a large number of bugs reported for Gimp-1.2 so please give it a try and torture it badly. If you think you found a bug, please file a bug-report at http://bugzilla.gnome.org/enter_bug.cgi?product=GIMP Specify the version 1.2.2-pre1 and include detailed information about your system and instructions on how to reproduce the bug. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] installing plugins
Hi, 0-rro [EMAIL PROTECTED] writes: I want to make my plugin, but have one problem - don't know how to install (/uninstall) plugin? If it is a single C file, gimptool is the tool of choice. Read the gimptool's manpage to learn how to use it. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: Gimp 1.2.2-pre2
Hi, another prerelease for Gimp-1.2.2 has appeared on the FTP server: ftp://ftp.gimp.org/pub/gimp/v1.2/testing/gimp-1.2.2-pre2.tar.gz This is not an official stable Gimp release, but unless users report problems with this release, the 1.2.2 release will follow shortly. This pre-release fixes a number of bugs that were found in the 1.2.2-pre1 release. I'd be happy if people could test it on a variety of platforms. If you think you found a bug, please file a bug-report at http://bugzilla.gnome.org/enter_bug.cgi?product=GIMP Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 1.2 Bug Hunting
Hi, Federico Mena Quintero [EMAIL PROTECTED] writes: I've had this problem, and it appears to exist only with the version of xwd that's shipped with XFree86 4.0.x where x=2. I upgraded to 4.0.3 and the problem went away. Same problem (with same version of X) existed with WindowMaker too. Oh dear. Don't tell me that the GIMP uses xwd for getting screenshots. If so, please please *please* feel free to steal the code from gdk_pixbuf_get_from_drawable(). it does ;-) The screenshot plug-in is kind of old and has always been a quick hack. On the other hand it works pretty well for most users... Yes, we are considering another solution for the next version of Gimp. Since we will use GTK+-2.0, we will also use gdk-pixbuf and can thus use the functionality gdk-pixbuf provides. For Gimp-1.2 however things will not change. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] removing the MPEG plug-in from the 1.2 distribution
Hi, we have had bug-reports about crashes with the MPEG plug-in as shipped with 1.2. The plug-in author and others agreed that the plug-in is a dirty hack. Since the quality of the plug-in does not match our standards and noone is willing to fix it, we are considering to remove this plug-in from the distribution. If you have serious problems with this decision, stand up now. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] translating The GIMP
Hi, I have been told that I can reach most of the gimp translators on the gnome-i18n list, so I'm sending this email to gnome-i18n and the gimp-developer list. If you reply, please consider not to cross-post unless you think your reply does belong to both lists. I'm one of the maintainers of current gimp development and I do unofficially maintain the translation of The GIMP for the stable branch too. There have lately been some confusions caused by the fact that The GIMP is at the moment developed in two branches and obviously there are translators working on The GIMP that are not subscribed to gimp-developer and do not know about this situation. I hope this mail clears some of this confusion. GIMP development is currently branched. The HEAD branch is undergoing major redesigns and it does not make sense at all to work on the translations in this branch. At the moment we are preparing the 1.2.2 release, a release in the stable gimp-1.2 series. Work on this is done in the gimp-1-2 branch and translators should focus on this branch and this branch only. If people absolutely want to spend time working on HEAD, go ahead, but do expect a lot of changes that may render your work obsolete. Today I found that www.klid.dk/gnome has po and pot files from gimp. People seem to use these files and even check translations based on these files into the stable branch. If the person responsible for www.klid.dk can be reached here, I ask him/here to remove these files. I'd like to use this opportunity to make some additional remarks on translating The GIMP. There is a file called README.i18n in the gimp source tree which explains how to translate The GIMP and names a few points that are special to The GIMP I18N. Every gimp translator should have read it! There's a copy available on the Gimp I18n page at http://sven.gimp.org/1.2/i18n.html From now on I'll post announcements about upcoming gimp releases to the gnome-i18n list too to remind translators to update their po files. Please note that the 1.2.2 release is going to happen very soon now. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: translating The GIMP
Hi, looks as if I have not been detailed enough (I'm referring to the latest addition of a new language to The GIMP that happened after my first email). Please do _not_ use gimp.pot files from any other source than GNOME-CVS module gimp branch gimp-1-2. Ask before you add a new translation to The GIMP. Run 'update.sh lang.po' before committing. You have to provide po files for all po directories as explained in README.i18n. Thank you. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Integrating the gradient-fu patch into GIMP 1.2.x
Hi, Shlomi Fish [EMAIL PROTECTED] writes: The patch is updated for GIMP 1.2.x and since I was told GIMP 1.3.x is going to have the UI code separated from the core, the developers refuse to integrate it there. My question is: while I adapt the patch to 1.3.x (or probably re-write a great deal of it from scratch) - can it be applied to the GIMP 1.2.x branch, so GIMPers will have its features now? Gimp-1.2 is ready and no new features will be added. Period. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] some gint - gboolean fixes.
Hi, David Odin [EMAIL PROTECTED] writes: I was looking in the gimp sources, and noticed some mixes between gint and gboolean. Here is a patch witch fixes all those I found. Sorry for replying that late. Just found your mail when I was checking the bunch of marked-as-important mails lurking in my mailbox. The patch looks good, but seems to be made against gimp-1.2. We will not change anything there unless it's an obvious fix for a reported bug. If you want to hack the gimp source (and you are very welcome to do so), please use the HEAD branch out of CVS. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Hi, Kelly Martin [EMAIL PROTECTED] writes: Why should we expect the GTK+ developers to keep their HEAD revision compilable at every moment? That is a completely unreasonable expectation in the first place. If I were a GTK+ developer I would be asking that you NOT do what you're proposing because it creates pressure on them to keep their HEAD workable at all times instead of doing what they need to do in order to further their own development. you are obviously not well informed about the current state of GTK+-2.0. The announcement of the latest releases (1.3.6 is the latest, 1.3.7 should be out pretty soon) had the following note: This release is meant for: * Those interested in the development of GTK+. * People planning to port to the upcoming GTK+-2.0 version of GTK+. Note: the API is mostly frozen at this point. Major API changes beyond the remaining open '2.0 API freeze' bugs in bugzilla are unlikely to occur before GTK+-2.0 is released. Now this is about five weeks ago and the API has been frozen in the meantime. The 1.3.7 release should give everyone a working and reasonably stable version to work with. As said, we use it every day for months now and I can only vaguely remember the one or two days when GLib, Pango, ATK and GTK+ from CVS HEAD didn't built out of the box. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Hi, Kelly Martin [EMAIL PROTECTED] writes: Why can't we just use 1.3.6? That's a frozen release that should be reasonably close to the eventual 2.0.0 release. who said, we couldn't do this? I do know that the current CVS HEAD works and has some smaller improvements but that could of course have changed since I last checked (yesterday). You are probably right that we should suggest using a release instead of CVS HEAD. There is simply NO good reason to be dependent on the CVS HEAD, no matter how stable the GTK developers think it might be. I think we do not really depend on it and 1.3.6 should work fine. At the moment our configure script wants 1.3.7 which has not yet been released. We can simply change this but I hope that anyway 1.3.7 will be out soon. There is a reason why we waited until the API freeze and a few weeks longer before we even considered starting the port. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: GIMP 1.2.2
Hi, Austin Donnelly [EMAIL PROTECTED] writes: Oops. It doesn't build out of the box. D'oh!!! rm -f $file PATH=../src:$PATH -o $file lt.po /bin/sh: -o: command not found make[2]: *** [lt.gmo] Error 127 make[2]: Leaving directory `/local/scratch/and1000/gimp/gimp-1.2.2/po-plug-ins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/local/scratch/and1000/gimp/gimp-1.2.2' make: *** [all-recursive-am] Error 2 It looks like something involved in making po files isn't present on my system and the makefiles or configure etc isn't coping. arghh, we did test this thing on a couple of systems without any problems. It looks as if for some reason or another lt.gmo files are missing from the tarball. No idea what went wrong on make dist here. I'll put up a new tarball fixing this problem. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: GIMP 1.2.2
Hi, there has been a problem with the 1.2.2 tarballs that made the build fail for people that don't have msgfmt (part of gettext) installed. I have built new tarballs that should fix this problem. Unfortunately some mirrors already have the old tarballs and it will take some time for them to catch up. The new fixed tarballs are: 9846904 Jul 27 07:05 gimp-1.2.2.tar.bz2 13520420 Jul 27 07:05 gimp-1.2.2.tar.gz Please excuse this inconvenience and let's hope the new tarballs work for you. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Hi, Adam D. Moss [EMAIL PROTECTED] writes: Michael Natterer wrote: Nick Lamb [EMAIL PROTECTED] writes: NB I am not blind and I don't write code in Hebrew I respect your extraordinary tolerance regarding this, so please respect that the people actually working on a project tend to make the decisions. Uh, that's pretty harsh if I read it right. Nick is a seasoned and consistant GIMP contributor. right, but the statement he made was unacceptable. I'm in no way a friend of political correctness, but I didn't believe my eyes when I read this sentence. Mitch probably overreacted here, but be assured that I wouldn't have found nicer words. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
Hi, Simon Budig [EMAIL PROTECTED] writes: Ok, I think we had a lot of arguments now. Could we try to agree on the following: 1) Currently Gimp CVS depends on Gtk+ CVS, because the improvements made in Gtk+ CVS (over 1.3.6) are very important for the lead developers. 2) When the first release of GTK+ with the fixed api appears (aka 1.3.7) Gimp CVS will depend on the earliest possible GTK+-Tarball. 3) When a bug in all GTK+-tarballs *massively* disturbs the GIMP developers and this bug is fixed in CVS we could make an exception to rule No. 2. However, this should be discussed on the Mailinglist. Yes, please. I don't understand why the discussion about depending on the CVS HEAD version of GTK+ came up in the first place. Of course we will try our best to be compatible with a GTK+ developers release. Noone will have to recompile his GTK+ each day just to take part in Gimp development. I wonder what made Kelly think this would be the case. It's probably bad experience with GTK+ ports back in the old days. GTK+ development as it happens now is a very strictly organized process and I'd say we can take the risk to trust Owen Co. I do believe that after the port is finished (very soon now) it will be much easier to work with the GIMP code. Large parts of the core will not even be dependant on GTK+ and the clean separation between different parts of the core will make it easier for one developer to concentrate on hacking on just one of those parts. This alone should make it way easier for developers with limited time to participate. Salut, Sven PS: I would like to mention that we all have to work for a living and noone of us can spend 120 hours a week on GIMP development. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] location of gdkx|win32|fb.h files
Hi Hans, nice to see that you started to hack on The GIMP again. I have a question regarding your commit as of yesterday: * plug-ins/common/animationplay.c : reflect that GTK2 has its gdkx|win32|fb.h files in the back-end sub directories this is true for the files in the GTK+ source tree. However it looks as if the files are installed as $(prefix)/include/gtk-2.0/gdk/gdk[x|fb|directfb].h I don't know about the win32 header file. Could you please check and correct this?! Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: GIMP 1.2.2
Hi, GIMP 1.2.2 is finally out and still a hadjaha release. ftp://ftp.gimp.org/pub/gimp/v1.2/v1.2.2/ This release fixes a large bunch of bugs, adds a couple of new translations and features a complete rewrite of the help pages. Happy GIMPing Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: GIMP 1.2.2
Hi, [EMAIL PROTECTED] writes: Please excuse this inconvenience and let's hope the new tarballs work for you. Really bad idea. This means that there are two versions of 1.2.2 floating around; one which build and one that doesn't. I'd REALLY suggest to update the version number I considered this, but decided not to do it since it will build on most systems out there. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] SMP support
Hi, Michael Soibelman [EMAIL PROTECTED] writes: I just noticed that there no longer seems to be the --with-smp configuration option! Is this an omission or intentional? IIRC, the configuration option to add support for multiple processors has always been --with-mp and it's still there. Also, excuse my ignorance, but can options such as --with-smp be passed to the rpm command rpm's do include prebuilt binary packages, you can't reconfigure them later. I suggest you build from source if you want SMP support. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] RFC: support for multi-image files and API change for load/save plug-ins
Hi, Raphael Quinet [EMAIL PROTECTED] writes: 3) Changes to the plug-in API The File-Open dialog would behave as follows: if the given path leads to a regular file, open it as usual (no extra path). If the path does not exist, then try to remove the last element from the path and see if there is a file (not a directory) with that name. If yes, open it and pass the remaining part of the path as a parameter to the plug-in. Repeat the shortening of the path until a valid file or directory is found. If a directory is found, then report a failure (file does not exist). The same thing would be done for File-Save. I don't think this is a good solution to your problem. It is in no way compatible with others programs or file system layers we might want to use in the future (like gnome-vfs for example). How is this supposed to work with non-local files? I don't think we want to wait for timeouts or interpret File not found error messages from a web|ftp|nfs|smb server while recursively stripping off stuff from our filename. If you want to support special filetypes that support filesystems inside files, please stay with standards and use a correct URI. As Nick already pointed out, the current API already supports this sort of stuff. If it needs additions or changes, we can of course change it now during the development cycle towards 1.4, but please let us find a reasonable solution. In order to support this, the file_load/save API has to be changed by adding one parameter (extra_path or path_info or something like that). This parameter would be NULL when a regular file is loaded or saved, but it would contain the name of the image when a multi-image file is edited. The only thing that would have to change in the current plug-ins is the addition of this parameter that would be ignored. The current plug-in API already allows to specify any number of additional parameters you like. As long as you document this, I can't see why this feature shouldn't be used. It's definitely a good solution for the non-interactive case. For the interactive case, a GUI to choose the relevant part of the file implemented inside the plug-in is probably what the user wants. The current API also allows the plug-in to store arbitrary data, so you can default to the last choice if the plug-in is subsequently used interactively. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp menu thumbnail
Hi, Guillermo S. Romero / Familia Romero [EMAIL PROTECTED] writes: IIRC, no new features will go into 1.2.x. this is correct. About GTK+, they are working in 1.3/2.0 now, so I doubt the patch will be applied. You should check what is going in CVS of both, and then see if it still applies, and how. current development GIMP in CVS uses the unstable GTK+ tree that has support for icons in menus and GIMP already makes use of this feature. We want to allow plug-ins to register an icon together with their menu entry and I'd prefer this solution over trying to create an icon automatically. It's a nice hack though and we might want to pick up the idea of applying the filters to a wilber image to create the plug-ins icons. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp menu thumbnail
Hi, myself wrote: We want to allow plug-ins to register an icon together with their menu entry and I'd prefer this solution over trying to create an icon automatically. I'm sorry, I hadn't looked close enough. Of course this is essentially what you did. I was under the impression you had managed to create the icons automatically by applying the respective filter to the wilber icon. We should consider using GParam and GParamSpecs as defined in GObject for an overhaul of the Gimp plug-in protocol. This needs some serious thoughts and discussions so we get it right and we should definitely consider extendending the plug-in registration to allow for menu icons when we do this. At the moment, the Gimp core is under heavy development, so I'd like to delay the implementation a little so we don't break everything at the same time, but it might be a good time to start to think about it... Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Patch] some more gint-gboolean changes.
Hi, David Odin [EMAIL PROTECTED] writes: I've sent this before, but the gimp's source tree changes too fast... This patch basically fix some function prototype which are said to return gint when they really return gboolean. I know this is not that important, but imho, gimp's sources look better with this patch ;-). thanks, I will commit your changes to CVS. P.S: Sven, this is an adaptation of the previous patch I sent you. I'm sorry, I've lost your answer during a mutt crash :-( iirc, my latest answer was that I don't think we need to change this in the stable tree although it shouldn't hurt. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Will the Gimp support the Layer Effects?
Hi, Iccii [EMAIL PROTECTED] writes: I wrote the script which simulate the Photoshop's Layer Effects. I think that the Layer Effects is nice feature. Will the Gimp support the Layer Effects in future? The script isn't easy to use because dialog doesn't preview the resulting image. http://isweb6.infoseek.co.jp/computer/wingimp/files/script/layer-effects_en .html I haven't looked at the script, but if we want to support Layer Effects, we need to define what layer effects are and need a proposal of how they could be implemented. Once we know what changes to the core are necessary, we can discuss if we want to include this feature for 1.4 or if we should wait for the 2.0 version where layer effects are part of the overall design. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] xwd screen shot problems
Hi, Robin Rowe [EMAIL PROTECTED] writes: Hi. Unless I'm mistaken xwd isn't capable of capturing 24-bit visuals. It seems almost useless on modern hardware. Is this an issue that has been discussed here before? it seems you are mistaken. What makes you think xwd can't capture TrueColor? How are you using the term 24-bit visuals here (24 bit color-depth or 24 bit aligned pixels) ? Attempting to capture graphics-intense windows with xwd on x86-based XFree86 3.x or 4.x just gives a misleading error message, extra confusing because other simpler windows on the same desktop will capture without trouble. what error-message ? The ImageMagic import utility works consistently and writes directly to png. Is there any thought to switching Gimp screen capture to use import? I was thinking about using some GDK features introduced in GTK+-2.0, but no new code has yet been written and we are open for suggestions. I don't think however that using import from ImageMagick is a reasonable solution. xwd is at least guaranteed to be available (on X11) which can't be said about ImageMagick. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: current gimp status and a patch for apply_lens.
Hi, David Odin [EMAIL PROTECTED] writes: I'm using current HEAD cvs of the Gimp. I've seen that all the filter plugins which use a GTK interface are crashing. Is this a known bug and is this due to the switch to the version 2.0 of gtk+? Is there anything I can do to help fixing this? yes, clean up your gimp installation. You obviously have old plug-ins installed. I've notice that plugins use gtk_signal* fonctions while the gimp application (under the app directory) use g_signal* ones. This lets me think the plugins are not yet converted to use gtk+-2.0. those that are in the current Makefiles should work. The gtk_signal_* functions are still OK, we just decided to totally switch to g_signal_* in the core to avoid to gtk_signal_connect() to a GObject. The GUI code in the plug-ins can continue to use gtk_signal_connect(). To be more precise, here are the plugins I've seen crashed on invocation : - destripe, - NL filter, - gflare, - gimpressionist, - gfig, - gdyntext, - imagemap, - jpeg. I haven't checked them all, but I think they have not yet been converted. This means they won't get installed and you are calling old executable. I'll look into your patch later... Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
Hi, Christophe Merlet [EMAIL PROTECTED] writes: You'll find a patch for the gimp/po/fr.po file attached to this mail. I hope this is the right list for this. Thanks, I'll commit your patch. feel free to commit, but please commit to the stable branch (gimp-1-2). Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: current gimp status and a patch for apply_lens.
Hi, David Odin [EMAIL PROTECTED] writes: Well, at least to make the jpeg plugins to compile (and works!) again, I just had to remove the '#' in front of its definition in plugin-defs.pl. Did I miss something important? if I remember correctly, the JPEG plug-in uses a textarea which is still in the GTK+-2.0 API but declared deprecated. This needs to be ported to GtkTextBuffer/GtkTextView. We have already done this for example in the Preferences dialog. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
Hi, Christophe Merlet [EMAIL PROTECTED] writes: This was a patch against the HEAD branch of gimp... then I've commited to the HEAD branch... fine. I just want to take the opportunity to explain once again how we treat translations at the moment and why we do it this way. The CVS HEAD version of The GIMP is under heavy development, it changes a lot and it is not intented to be used by anyone but developers working on it. It will crash, bring down your computer, wipe your harddisk and don't tell us later, we didn't tell you. For this reason it is a waste of time to keep translations uptodate. Instead translators should focus on updating and correcting the translations in the stable branch. The plan is to have a 1.2.3 release at some point with updated translations and help files plus probably a few bug-fixes. At some point (pretty soon now), I will merge the translations from the stable branch to HEAD so your updates won't get lost. If you update HEAD, but fail to update the stable branch, chances are your work will be lost. One more thing to consider: Localisation in GIMP HEAD is considerably broken since we have to switch all the po files to UTF-8. You can create some nice crashes if you try to start GIMP from CVS HEAD with LC_ALL != C since GTK+-2.0 doesn't like to be passed invalid UTF-8 strings. The number of warnings I see when trying to start unstable GIMP with LC_ALL=fr_FR makes me one more time believe that translators don't even try their translations before committing them or asking people to commit. It would be very nice if David could create a patch against the stable version since his updates look very good and I wouldn't like to loose this work. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Translating The GIMP
Hi, I plan to merge translations from the stable gimp branch (gimp-1-2) to the HEAD branch very soon now and hereby ask all translators to assure that the translations in the stable branch are up-to-date. If you have committed changes to the HEAD branch, please make sure the stable branch contains your fixes, otherwise your changes will get lost. The po files in GIMP HEAD will be converted to UTF-8 since GTK+-2.0 requires strings to be UTF-8 encoded. I will check in some simple tools that allow you to convert between native encodings and UTF-8 since only few editors out there support UTF-8 directly. For now you don't have to worry about this and I will post some detailed explanations after I have completed the changes in the HEAD branch. For now, all you have to care about are the po-files in the gimp-1-2 branch. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Translating The GIMP
Hi, Karl Eichwalder [EMAIL PROTECTED] writes: It isn't up to you as the program maintainer to merge translations from STABLE to HEAD or something like that. Provide hints how translators might proceed, but please don't change contents of the files. I have always asked people not to touch po files in CVS HEAD at all. Until we change this rule, the po files are in the maintainers responsibility. Some people working on the po files don't have CVS commit access, so I can't simply ask them to do the conversion. Here is what needs to be done, so we can work out a plan how it can be done best: (1) Some new languages have been added to the stable branch. These need to be added to the unstable branch. (2) Updates to translations from the stable branch need to be merged. Merging in this context means copying the po files from the stable branch to unstable and running msgmerge on them. Since we haven't changed many strings yet, this should give reasonable results. (3) We need to handle the UTF-8 problem somehow. GTK+-2.0 solved this by keeping UTF-8 encoded po files in the tree and I do like this solution but I'm open for suggestions. But that's not a valid reason to force the translators to deal with UTF-8 if they don't want to. GTK developers think they need .mo files using UTF-8 (why?) convert them at installation time, please! what benefit does this give? Converting at installation time is not possible since we can not require the user to have the appropriate tools installed. We could do it at release time, but this wouldn't fit into the 'make dist' scheme. I see no real alternative to UTF-8 encoded po files in the tree. PO files are translators land. Maintainers don't have the right to convert them into another charset. Leave these files alone, please. as said above, I consider po files in gimp CVS HEAD maintainers land. Translators have been asked not to enter this area multiple times. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Thin lines using pencil
Hi, Grzegorz Borowiak [EMAIL PROTECTED] writes: Thank You guys. It seems drawing a good thin non-antialiased line is so foar not implemented, I hope it will be. I could do it, but it would take a long time for me to understand code and the whole conception of GIMP. right now pencil and paintbrush are exactly the same tool with the slight difference that the paintbrush calls gimp_paint_tool_paste_canvas() with BrushApplicationMode == SOFT (or PRESSURE for pressure-sensitive painting) while the pencil uses HARD here. This leads to different ways how the brush_mask is prepared. For SOFT mode the brush mask is subsampled to the brush position using a 5x5 subsampling kernel while HARD mode solidifies the brush by setting all pixels to full opacity that are non-NULL in the brush pixmap. The relevant code for painting can be found in app/tools/gimppainttool.c. There could be problem if brush size is big and line has to be half-transparent. E.g. brush radius is 10 and intensity is 0.5. There would be 1-pixel-close overlapping brush hits, whose intensities would accumulate. But this problem can easily be compensated if we use more sophiscated tool_t function, which would reasonably decrease its intensity (simply dividing nominal intensity by radius size and then by sine/cosine value of line angle) for all pixels except two ends, and these two ends would be painted with full nominal intensity, but only half of brush would be painted (this half which does not overlap with any mid-line brush hit). I don't think this would work well. Instead I'd suggest to draw the brush totally opaque to intermediate tiles, then blend these with the choosen brush opacity onto the drawable. Might be more memory-intensive but should give perfect results. On the other hand it would diverge a lot from what happens if you draw a line by hand. Would it make sense to consider a line-drawing tool? I think it would be especially useful to stroke selections and paths. Our current approaches to stamp the brush at equidistant positions along the outline does not give pleasant results and all attempts to improve this will most probably only mess up the (already weird) code. Such a line-drawing tool wouldn't work with brushes but would have configurable line-width and cap settings. I might be wrong, but I think the ink tool might be suited reasonably good for proper line drawing. If it would have support for drawing straight lines using the Shift key, we could test it and this should be easy to implement. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Translating The GIMP
Hi, Karl Eichwalder [EMAIL PROTECTED] writes: what benefit does this give? Converting at installation time is not possible since we can not require the user to have the appropriate tools installed. We could do it at release time, but this wouldn't fit into the 'make dist' scheme. release time sounds good to me. I'd recommend to modify the 'make dist' target and send a feature request to Bruno Haible. There's at least one project which goes this road since a year(?). I don't think release time is a good solution. First, we need this feature now and I don't want to require gettext from CVS. Second, we want to have useable po files in the tree all the time so gimp from CVS is useable even if LC_ALL != C. I see no real alternative to UTF-8 encoded po files in the tree. I'm all for UTF-8, but every single language team should decide when the time has come. do you really think the additional step of converting to UTF-8 before committing is too much for our translators? I don't think so. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] (no subject)
Hi, Vranyecz, Zoltan [EMAIL PROTECTED] writes: How could I unsubscribe, from the GIMP mailing list? ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer the answer is right there in your mail (check the URL above). Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: patch for gimp/po/fr.po
Hi, Kelly Martin [EMAIL PROTECTED] writes: On 29 Aug 2001 10:59:06 +0200, Sven Neumann [EMAIL PROTECTED] said: One more thing to consider: Localisation in GIMP HEAD is considerably broken since we have to switch all the po files to UTF-8. You can create some nice crashes if you try to start GIMP from CVS HEAD with LC_ALL != C since GTK+-2.0 doesn't like to be passed invalid UTF-8 strings. Has this been reported as a bug in GTK? Huh? It's not a bug, it's a feature. All strings in GTK+-2.0 are UTF-8 encoded and the application has to assure that only valid UTF-8 strings end up at the toolkit level. This is the only reasonable solution to the encoding mess and it works just perfect. It allows for example to have different languages with different native encodings in the same widget. Why do you consider this a bug? Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
