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
Hi, Branko Collin [EMAIL PROTECTED] writes: Am I to understand that there is no recorded instance of this discussion? Well, let's start now, then, so that next time we can point to the mailing list archives. The mailing list archive definitely has at least parts of this discussion. Since we did not come to a conclusion last time, the archive is however not very helpful and you are right in pointing out that we should start it all over now. First of all a definition of the problem area: what are considered plug-ins? Everything that goes into the directory 'plug-ins'? Anything else? Scripts are definitely in the same category. In the future we will also see pluggable tools and its foreseeable that we will face the same problems there at one point. My suggestion is that the following plug-ins belong to the core distribution: - those that perform a task that the GIMP should have provided for itself or will provide for in the future; Our goal is to have as much functionality as possible in plug-ins. This reduces the size of the core, makes it cleaner and improves maintainability of the core. This makes this rule questionable especially since a task that the Gimp should provide is much too vague. - those that will help other plug-in authors better understand how to write plug-ins; We have a plug-in template for this task and I don't see what would stop plug-in authors to have a look into the plug-in packages that are distributed seperate from the core gimp package. - those that will make the GIMP look good when compared to other raster image editors Only because another program has a certain functionality does not make it necessary to distribute the same functionality with core Gimp. - those that perform a task the best in its field. Not a very useful definition either. Those plug-ins will most likely be pretty large and only useful to a subset of users. Thus they belong into a special package. Can such a distinction be made? You are right that we need to make such a distinction, but I don't think the rules you suggested make much sense. On the other hand I think we should first discuss how the gimp packaging should look like in the future instead of tackling the problem which plug-ins go into which package. I'll try to summarize some of the ideas that have come up during earlier discussions: A very important point for distributing a plug-in is to have a maintainer that feels responsible for it. The core Gimp maintainers would like to only have a set of basic image manipulation tasks in the core package and they would feel responsible for keeping them up to date, handling bug-reports and discussing patches. Such basic plug-ins would include for example Blur, Gauss-Blur, Sharpen, Rotate, and a set of important file-plug-ins to give only a few examples. Other plug-ins could be grouped into smaller packages for special purposes. For example there could be a gimp-web-plug-ins package that adds functionality like GIF-Save, Anim-Optimize, ImageMap and others. Such a package would have a maintainer who is responsible to handle bug-reports and keeping the package in sync with the core. Installing gimp would then be a process of installing gimp-core and a set of plug-in packages that fit the needs of the user. Such an approach has some obvious advantages but also a bunch of drawbacks: The packages would have interdependencies. The web-plug-ins package might include a gimp-perl script so it would require gimp-perl. Of course everything in the web-plug-ins package but this script would work w/o gimp-perl so actually gimp-perl is not required but only recommened. I can however only think of one binary package system that can handle those kind of weak interdependencies (debian). The packages should not overlap and they should share the menus intelligently. This would require some interaction between package maintainers. I think however that this should be doable. On multi-user systems the administrator who installs gimp can not decide what packages the users might want. One solution is to install them all. This would however lead to overcrowded menus. A problem that could be solved by a plug-in manager that knows about all plug-ins that are available and lets the user choose what plug-ins she wants to see in the menus. Having gimp split up into dozens of packages will make installation difficult. Again a plug-in manager that knows about all available plug-ins out there, collects and installs them would help. It turns out we need a plug-in manager. What functionality should such a beast have? Here's a list of things that came to my mind: It should read a number of plug-in lists: a list of all available plug-ins that is distributed with the core gimp and can be updated through the web. A list of plug-ins that are installed locally do not necessarily appear in the menus. It should have meta-packages of plug-ins similar to the task-lists Debian has so a user
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
Hi, David Monniaux [EMAIL PROTECTED] writes: The installation process is frightening: 1. The user is presented with a dialog box Welcome to GIMP that is half full of legalese (NO GUARANTEE etc...). actually our first version had an Accept button at the bottom ;-) The GPL wants you to put a visible notification about the license into your program. This notice should be seen whenever you start Gimp. We only show it on user installation and one day RMS will come and get us for this lazyness. I think the license part should stay and we should add an additional note about the GPL to the About dialog. Perhaps the first installer screen should simply state that Gimp is a painting, touch up etc... program able to read various image formats etc..., and the legalese should be pushed to a second dialog box ? if you think adding a useless advertisement page to the user installation will help, I wouldn't object adding it even though I don't see the point. 2. The current second dialog box shows a full list of files and directories that most users will never care about at first. Maybe we should add an indication that knowing all about this is not necessary to use Gimp? I think it is very nice that we don't quietly install a bunch of dirs and files in the users home directory without telling him. Perhaps we should indeed change the accompaigning words. Patches are welcome. 3. The installer runs a script that copies files and asks the user to spot an error in the execution of the scriptx and investiguate in case there is an error. [even worse in the Windows version] Come on. Users do not know about scripts, and they do not know what an error looks like [*]. The installation process should see by itself if an error has happened, and display a meaningful error message in that case. It's not that easy. Don't think we didn't try it. Again, patches are welcome. 4. Adjustment of parameters Another frightening dialog box. We should really convey the idea that the default settings are OK, and that those settings can be changed at any time afterwards (otherwise the users may spend time pondering what to say here). It is indeed possible to change this later, but we moved it into the user installation since experience shows that these values will never be adjusted later. Setting the tile cache correctly is viable for a good user experience so I expect the user to spend some time here pondering what values to choose. a) The default tile cache size should be adjusted with respect to the installed RAM size. This should fulfill the need of most users (PCs with one console user). In the case of multi-user systems, the system administrator should be able to set other default values (maybe depending on the machine). Yeah, we had that discussion before quite often and everyone agreed that it should be as you say here, but until today noone found it important enough to change the code. Many people just leave the default of 32M, open a big image and claim that Gimp is s much slower than PhotoShop. If those people knew better, they'd heard their hard drive churning and understand that Gimp is swapping, but this should not be expected from most users - how do you think that computer resellers sold boxes with fast CPUs and only 32M of RAM ? That's exactly why we've put the tile cache size setting into the user installation process. Furthermore, we should add the precision that the value there should not be the total amount of RAM in the machine, but the size of the portion of that full RAM that should be used for Gimp images. Here's what is written: GIMP uses a limited amount of memory to store image data, the so-called Tile Cache. You should adjust its size to fit into memory. Consider the amount of memory used by other running processes. Well, not the best description propably. Please send a patch for a better one. b) The setting of the swap file in .gimp-x.y/tmp is a problem on NFS-mounted accounts (universities, for instance). Why not /tmp by default? Since /tmp is not always a good choice, it might even not exist?! For that reason we say: All image and undo data which doesn't fit into the Tile Cache will be written to a swap file. This file should be located on a local filesystem with enough free space (several hundred MB). On a UNIX system, you may want to use the system-wide temp-dir (/tmp or /var/tmp). Don't you think this is enough to help the user make a good decision? Now for the main UI. We should have a way to remind people to use the RIGHT BUTTON on the image. I bet many people think Gimp is some kind of small MS Paint-like program because they have never been able to reach the filters. Yes, I know this is the second tip, but... Overall I don't like the idea of treating the user like an
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
Re: [Gimp-developer] Translating The GIMP
Hi, Branko Collin [EMAIL PROTECTED] writes: On 29 Aug 2001, at 11:22, Sven Neumann wrote: 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. I noticed that somebody else than me has commited Dutch translations to HEAD. I tried to contact that translator once, but got nowhere. I will try again (also contacting the person who actually commited the new strings, as that was a third person), but ask in the meanwhile that the stable translation will not be merged with those changes without contacting me first, as I do not want to start juggling three different translations (the one in HEAD, the one in 1.2.2 and the one on my hard drive). whoever committed to HEAD made a mistake and it is my intention to not merge the translations but simply take the ones from gimp-1-2 into HEAD thereby overwriting any changes that have been applied to HEAD but not to the stable branch. For this reason I've asked the translators to update their translations in the stable branch now. All I want to achieve at the moment is to get a set of working translations for the 1.3.0 developers release. Those translation need not to be complete and there will be plenty of time to update the translations when we approach the stable 1.4.0 release. For the HEAD branch, we should try to find a responsible translation maintainer for each language. The language maintainer should have CVS commit access and is responsible for coordinating his/her team of translators. 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: Sven Neumann [EMAIL PROTECTED] writes: 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. Sure, but a simple script calling iconv or recode will do it. we can not assume that iconv or recode is available on all target platforms. 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 don't understand this argument. I don't understand your argument either, but let me explain mine. The GIMP should work as checked out of CVS, so either we have UTF-8 po files in CVS (like GTK+ does) or we need to convert to UTF-8 during generation of the mo files. This would require the availability of the necessary tools on the build platform which we can not safely assume. IMO the easiest solution is to go for UTF-8 po files in CVS. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Translating The GIMP
Hi, Christian Rose [EMAIL PROTECTED] writes: 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. I do not agree. Committing PO files to HEAD in any project is always risky business (large frequent changes im messages), and time for translating is always better spent in the stable branch, if there is one. HEAD is secondary at best, and translators should know what they are doing if they touch the HEAD branch. That I agree on. But I think it's stupid to entirely forbid committing translations to the HEAD branch, if the translators know what they are doing. Why? Because of testing. I didn't forbid it, I only tried to encourage people to concentrate on the stable branch. Now I want to weaken this policy since we are approaching a developers release. I had the idea of helping translators by bringing the translations in the unstable tree uptodate with the stable tree so they have something to start with. I think I am now convinced that I shouldn't do this. The problem is however that some of our translators don't have commit access and have been promised that their translations will be added to the unstable tree when the time has come. Well, the time has come, so what am I supposed to do? Translators know what charset is best suited for the locale, and works with the translation tools they use, developers don't. well, I do know that we need UTF-8 encoded strings for GIMP since we use GTK+-2.0. IMO the best solution is to enforce UTF-8 encoding for our po files just like GTK+ does. For the HEAD branch, we should try to find a responsible translation maintainer for each language. The language maintainer should have CVS commit access and is responsible for coordinating his/her team of translators. You've just described the GNOME Translation Project. hmm, not all of our translators are part of the GNOME translation project and GIMP != GNOME. For that reason, I'd like to maintain a list of language maintainers in the GIMP source tree. If the GNOME translation project wants to take this job and thinks such a list is a waste of time, this is something we can and should consider, but it needs to be discussed. I really appreciate all the help I can get here and don't feel comfortable maintaining GIMP translations, but at the moment people send po updates to me. I'd prefer if this job could be taken by someone else and if the GNOME translation project stands up and wants the job, just tell me to whom I should send people with translation updates in the future. I would really love to be able to concentrate on real hacking again. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Translating The GIMP
Hi, OK, here's what I came up with as a (preliminary?) solution. I've added a link to the GNOME Translation Project's homepage to README.i18n and will refer all people willing to contribute to GIMP's localisation to the GTP. I'll do the same with people sending me translations and I ask everyone to do the same. The people from the GTP have CVS commit access and some coordination on the i18n front is most probably a good idea. I have added a note to README.i18n in the unstable branch explaining that GTK+-2.0 requires UTF-8 strings and that we require UTF-8 encoded po files (and tips files) for that reason. We do not do any implicit conversions so any po files that are not UTF-8 encoded will not work. If someone comes up with a reasonable way to do on-the-fly conversion, I'll consider adding it, but first I want to hear a good reason from an active translator why she thinks dealing with UTF-8 encoded files in CVS is too much of a burden. I hereby encourage translators to convert their po and tips files in gimp HEAD to UTF-8. The gnome-i18n module in CVS has some scripts that help with this task. If you feel like updating the translations in the HEAD branch, feel free to do so, but expect lots of strings to change. Your main concern should however be to finish and polish translation of stable gimp as found in the gimp-1-2 branch. I will not touch any po files except the german ones any more except for trivial fixes that break the build. Please excuse if I may have sounded harsh during this thread; I didn't want to step on anyone's feet. 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 Jay, Jay Cox [EMAIL PROTECTED] writes: I have commited a fix for this bug to the 1.2 branch in CVS. will you fix this in the HEAD branch too? The code is now in app/tools/gimppainttool.c. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] suggestion for color to alpha
Hi, Lourens Veen [EMAIL PROTECTED] writes: Open image Select Filters-color-to-alpha, popup appears Select color picker, another popup appears Get colour from image, it shows up in the color picker popup Drag the colour to the color-to-alpha popup Select OK You can also drag'n'drop colours from palettes and the Gimp main window. and additionally you can right-click the color-area to get a small menu that allows to take the global FB or BG color. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Patch for gimp HEAD
Hi, Thomas Canty [EMAIL PROTECTED] writes: 1. The coding standard specfies that tabs are not to be used, however tabs are used throughout the source code. Why is this? because we haven't yet eliminated them all? The coding standard describes how we would like new code to look like and we appreciate any effort to convert existing code to this standard. 2. I have tried using 'indent' to indent the code according to the coding standards, however this does not produce satisfactory results. (i have tried various options including the standard GNU style) it would be very nice if indent would create satisfactory results, but it seems it doesn't. Sometimes 'indent --gnu' is a good start but the code needs a lot of finetuning by hand afterwards. What's the best way to make the code comply with the coding standards? use the standard emacs settings and add the following line to your .emacs to suppress insertion of tabs: (setq c-mode-common-hook '(lambda () (setq indent-tabs-mode nil))) Here is a patch which replaces some depreciated GDK functions, Okay to commit?, looks good to me, go ahead. 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, [EMAIL PROTECTED] (Carsten Hammer) writes: I think there are more such obvious bugs that are revealed in special cases. here is what you should do about this: - file a bug-report on bugzilla.gnome.org so your report won't get lost - send a patch that fixes the problem Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Need quick development workstation
Hi, Winston Chang [EMAIL PROTECTED] writes: I wrote the GIMP unsharp mask plugin a while back and I'm looking to add a preview window to it. I wrote the code just now and I tried to compile the latest CVS tree but the GIMP won't build at all for me. I don't know much about autoconf, but I assume I have to run autogen.sh or autoconf. autogen.sh complains: Testing gettextize... too old! (Need (0.)10.38, have 10.35) and autoconf makes a configure script that complains: ./configure: line 570: syntax error near unexpected token `AM_INIT_AUTOMAKE($PACKAGE,' ./configure: line 570: `AM_INIT_AUTOMAKE($PACKAGE, $VERSION, no-define)' Anyway, I don't feel like going to the trouble of updating my libraries or whatever it is I need for this little modification, so if I could have short-term ssh (with X) access to a machine that can build the latest CVS branch, I'd really appreciate it. I promise not to do anything bad -- besides, you should have the latest patches installed anyway. :-) all I can offer you is to help you with upgrading your libraries. The files HACKING and README should give you a good overview of what you need. If you have problems, ask. So you are working on plug-in preview. Did you consider to resurrect the code or at least the idea of a generic preview suitable to be used by all (or most) plug-ins? I think now is a good time to add such a feature since almost all plug-ins would benefit a lot from having a preview and it does IMO not make sense to duplicate the same code all over the place. The code I'm speaking about can be found at ftp://ftp.gimp.org/pub/users/amundson/gimp_plugin_preview-0.29.tar.gz Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Solaris 64bit compile
Hi, Mattias Engdegård [EMAIL PROTECTED] writes: I don't think they are that bad --- the readability of the above code merely suffers from a pollution of backslashes and underscores. I took this code out of a macro and forgot to remove the backslashes. Also we'd use different types since glib defines guint8, guint16 and guint32. I choose not to show off the code for RGB16 and RGB15 since the masks and shifting values used there make the code hard to understand, while the RGB32 and ARGB cases are more obvious. Also fortunately, we don't do RGB16 in gimp. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] suggestion for color to alpha
Hi, Daniel Egger [EMAIL PROTECTED] writes: Am 06 Sep 2001 12:56:46 +0200 schrieb Sven Neumann: I think Branko is right here. Color-To-Alpha is not suited for chroma-keying since it will remove all shades of blue from all colors in the image. Classic blue-boxing requires to clear only exactly the color defined as the blue-box background. This can easily be achieved using Select-By-Color with a small threshold followed by Clear. I believe a good chroma keying algorithm would have to work a bit differently because in real life one has the problem that the blue of bluebox might vary slightly because of lighting conditions. So maybe the best would be to go over the HSV colorspace to allow a choosable variance in the keycolor? Select_By_Color takes care of that but operates only in the RGB domain. It might be a good idea to add an option that allows to apply the threshold to the HSV colorspace. If someone wants to hack this simple function, please port by_color_select to libgimpcolor and add generic color_distance functions to libgimpcolor. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Fix for the gif plugin.
Hi, David Odin [EMAIL PROTECTED] writes: OK. I've attached a similar patch for the gif plugin. It does basically the same thing as my patch for the jpeg plugin (replacing a GtkText by a GtkTextView/GtkTextBuffer couple). I've two question about this plugin: - why gifload and gif are kept separated, when, for most image formats, the loader and the saver is in the same plugin? - the code of gif.c looks unmaintained, and rather dirty (lots of code commented out, define for FACEHUGGERS, no real copyright notice, etc.) Who is the current maintainer? as stated in PLUGIN_MAINTAINERS Adam D. Moss [EMAIL PROTECTED] maintains the gif plug-ins. He should be able to tell you why he chose two separate plug-ins (licensing?!). Oh, and yes, Adam has this very special british humour that makes his code fun to read... Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] configure error in cvs
Hi, safemode [EMAIL PROTECTED] writes: Ok, compiling gtk+ from the cvs and i'm getting this error. gdk-pixbuf.c:395: parse error before ')' token gdk-pixbuf.c:396: parse error before ')' token gdk-pixbuf.c:397: parse error before ')' token make[3]: *** [gdk-pixbuf.lo] Error 1 it seems to be because the version variables aren't declared anywhere or set correctly. Manually assigning the numbers 1 3 and 7 to them allowed the file to be compiled but because the version information isn't being set right, linking eventually failed with this libtool: link: CURRENT `-' is not a nonnegative integer libtool: link: `-::-' is not valid version information make[3]: *** [libgdk_pixbuf-1.3.la] Error 1 are you sure you've successfully run autogen.sh? This looks as if something went wrong earlier. There is absolutely no warnings in autogen.sh There is a warning in configure script 1st thing it outputs. This is what it says. configure.in:165: AC_PROG_CPP was called before AC_PROG_CC this one is harmless. I've just updated my CVS trees and everything compiles just fine. The gdk-pixbuf version numbers are defined in gdk-pixbuf-features.h which should be created from gdk-pixbuf-features.h.in when configure is run (or config.status more precisely). Try 'make clean -k' and rerun autogen.sh. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] new releases of GTK+ and friends
Hi, new releases in the development series of glib, Pango, Atk and GTK+ have appeared on the FTP servers. I have just committed a bunch of changes for The GIMP so that the HEAD branch compiles against these releases. Actually it now requires these releases to build successfully. In particular you need glib-1.3.8 pango-0.19 atk-0.4 gtk+-1.3.8 You will also need to have libtiff, libpng, freetype2 and pkgconfig installed before installing the packages mentioned above. We will try our best to keep the HEAD branch of The GIMP compatible with these releases for a while (preferably at least until a new version of GTK+ is released). A lot of stuff in The GIMP is broken at the moment (most noteably the Text Tool), but it is nevertheless a good moment to give it a try. We consider doing a 1.3.0 release as soon as some of the outstanding issues are solved, but I do hereby encourage the brave and curious among you to install the packages mentioned above and check gimp HEAD out of CVS. Any feedback and especially any help is very much appreciated. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script-Fu server parser bug?!...
Hi, NunoACHenriques [EMAIL PROTECTED] writes: Greetings! When the run-mode of a script-fu is turned to non-interactive (=TRUE or =1) I get a very strange error message: ... /usr/bin/gimp: Script-Fu Error while executing (script_fu_text_nach FALSE /tmp/ /tmp/ /tmp/ /tmp/ FALSE '(39 36 95) '(39 36 95)) ERROR: unbound variable (errobj /tmp/) it would help a lot if you could provide a complete test case for this problem. How are we supposed to reproduce your problem without the script you are trying to run? Could you please check if you can reproduce the problem with one of the scripts from the standard gimp distribution and report back. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] gimp HEAD and glib from CVS
Hi,
we have tried to keep the CVS version of GIMP compileable with the
latest releases of GTK+ and friends as well as with the current state
of these modules in CVS. The latest (small) changes in glib break
source compatibility and since the glib version number has not yet
been incremented, I don't see a way to conditionalize the code so
that it works with both versions of glib. As a first solution, I'm
posting a patch here for the people among you that follow CVS
development of glib, pango, atk and gtk+. I'd like to know how many
of you would prefer to have this changes applied to the gimp CVS
tree now and how many would prefer us to stay source compatible with
the latest glib, pango, atk and gtk+ development releases.
Salut, Sven
Index: libgimpbase/gimpparasiteio.c
===
RCS file: /cvs/gnome/gimp/libgimpbase/gimpparasiteio.c,v
retrieving revision 1.9
diff -u -r1.9 gimpparasiteio.c
--- libgimpbase/gimpparasiteio.c2001/08/01 00:35:48 1.9
+++ libgimpbase/gimpparasiteio.c2001/10/02 17:32:26
@@ -161,8 +161,8 @@
for (i = 0; i params-dim; i++)
{
- g_string_printfa (s, rank%d:%d, i, params-rank[i]);
- g_string_printfa (s, sel%d:%s, i, params-selection[i]);
+ g_string_append_printf (s, rank%d:%d, i, params-rank[i]);
+ g_string_append_printf (s, sel%d:%s, i, params-selection[i]);
}
str = s-str;
Index: plug-ins/ifscompose/ifscompose_storage.c
===
RCS file: /cvs/gnome/gimp/plug-ins/ifscompose/ifscompose_storage.c,v
retrieving revision 1.8
diff -u -r1.8 ifscompose_storage.c
--- plug-ins/ifscompose/ifscompose_storage.c2001/08/01 00:35:57 1.8
+++ plug-ins/ifscompose/ifscompose_storage.c2001/10/02 17:32:26
@@ -27,6 +27,7 @@
#include ifscompose.h
+
enum {
TOKEN_INVALID = G_TOKEN_LAST,
TOKEN_ITERATIONS,
@@ -422,8 +423,9 @@
scanner-input_name = IfsCompose Saved Data;
for (i = 0; i nsymbols; i++)
-g_scanner_add_symbol (scanner,
- symbols[i].name, GINT_TO_POINTER (symbols[i].token));
+g_scanner_scope_add_symbol (scanner, 0,
+symbols[i].name,
+GINT_TO_POINTER (symbols[i].token));
g_scanner_input_text (scanner, str, strlen (str));
@@ -450,51 +452,51 @@
gint i;
GString *result = g_string_new (NULL);
- g_string_printfa (result, iterations %d\n, vals-iterations);
- g_string_printfa (result, max_memory %d\n, vals-max_memory);
- g_string_printfa (result, subdivide %d\n, vals-subdivide);
- g_string_printfa (result, radius %f\n, vals-radius);
- g_string_printfa (result, aspect_ratio %f\n, vals-aspect_ratio);
- g_string_printfa (result, center_x %f\n, vals-center_x);
- g_string_printfa (result, center_y %f\n, vals-center_y);
+ g_string_append_printf (result, iterations %d\n, vals-iterations);
+ g_string_append_printf (result, max_memory %d\n, vals-max_memory);
+ g_string_append_printf (result, subdivide %d\n, vals-subdivide);
+ g_string_append_printf (result, radius %f\n, vals-radius);
+ g_string_append_printf (result, aspect_ratio %f\n, vals-aspect_ratio);
+ g_string_append_printf (result, center_x %f\n, vals-center_x);
+ g_string_append_printf (result, center_y %f\n, vals-center_y);
for (i=0; ivals-num_elements; i++)
{
g_string_append (result, element {\n);
- g_string_printfa (result, x %f\n, elements[i]-v.x);
- g_string_printfa (result, y %f\n, elements[i]-v.y);
- g_string_printfa (result, theta %f\n, elements[i]-v.theta);
- g_string_printfa (result, scale %f\n, elements[i]-v.scale);
- g_string_printfa (result, asym %f\n, elements[i]-v.asym);
- g_string_printfa (result, shear %f\n, elements[i]-v.shear);
- g_string_printfa (result, flip %d\n, elements[i]-v.flip);
- g_string_printfa (result, red_color { %f,%f,%f }\n,
-elements[i]-v.red_color.r,
-elements[i]-v.red_color.g,
-elements[i]-v.red_color.b);
- g_string_printfa (result, green_color { %f,%f,%f }\n,
-elements[i]-v.green_color.r,
-elements[i]-v.green_color.g,
-elements[i]-v.green_color.b);
- g_string_printfa (result, blue_color { %f,%f,%f }\n,
-elements[i]-v.blue_color.r,
-elements[i]-v.blue_color.g,
-elements[i]-v.blue_color.b);
- g_string_printfa (result, black_color { %f,%f,%f }\n,
-elements[i]-v.black_color.r,
-elements[i]-v.black_color.g,
-elements[i]-v.black_color.b);
- g_string_printfa (result, target_color { %f,%f,%f }\n,
-elements[i]-v.target_color.r,
-
[Gimp-developer] Re: GIMP Tip of the Day messages
Hi, Christian Rose [EMAIL PROTECTED] writes: Hmm, would it be possible to make GIMP tips translatable in a po file in the future? That would probably ease translation, since gettext has some nice features: it's easy to compare the original message and the translation, easy to spot messages that changed or new messages, and so on. The messages could be put in a header file, or an XML file of some sort (if you use intltool/xml-i18n-tools). If it's too much to put in gimp.pot, it could be a translation catalog of its own. What do you think? I'm all for it. I have already considered doing such a change in gimp HEAD. I'd favor a separate translation domain for the tips since we could avoid to bind to this domain until the tips dialog is actually shown. A header file with static strings should probably do the trick most easily or do you think an XML file would give any advantages? Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
