Gimp Traffic #15 For 24 Feb 2000

By Alex Harford

Table Of Contents

Mailing List Stats For This Week

We looked at 194 posts in 648K.

There were 57 different contributors. 31 posted more than once. 18 posted last week too.

The top posters of the week were:

1. Removing Unused Selection Code

13 Feb 2000 - 14 Feb 2000 (2 posts) Subject: "Dead code in app/selection.c?"

People: Sven NeumannSven Neumann Tor Lillqvist

Tor Lillqvist thought he found some dead code in selection.c, in the #else part of an #ifdef that would always be true. Sven Neumann replied, "You better do clean that up then. Get rid of the dead bytes before they start to smell." There were no more messages in this thread.

2. Adding Save Copy, Autosave, and Color History

14 Feb 2000 (4 posts) Subject: "Some suggestions"

People: Thomas LinderAustin DonnellyTom Rathborne

Thomas Linder had some suggestions for the gimp developers:

  1. Save Copy As...
    with its own set of file paramaters including filename
  2. Autosave
    option to save automatically at regular intervalls
  3. Color History
    quick select from recent colors, either as popup menu in color section or by creating a new palette (optionally) to be saved - or both perhaps.

Austin Donnelly replied that "Save Copy As..." already existed, as "File/Save as..."; he added that an Autosave feature would probably not be difficult to implement, but that the feature-freeze prevented it at the moment. Finally, Austin explained that the Color History feature could be implemented as a "colour selector dynamically loadable module."

Tom Rathborne clarfied Thomas' suggestion. "I think what he meant was that "Save Copy As..." would save the file _without_ changing the name of the image. That is, the next call to "Save" would write to the original filename rather than that used in "Save Copy As..."."

Thomas explained his thoughts on the Color History:

My first idea was to have it in the color part of the main toolbox as a pop-up menu bound to the color-buttons... Having an auto-palette that gets saved was my second idea - both appear good to me but the first option may be an inconsistent addition to the current user-interface.

I think I remember someone saying the toolbox already has too many buttons and therefore should be redesigned some day. I can't remember though if the suggested solution was by making popup boxes to more general buttons. This could make my first proposal for color history consistent with toolbox handling.

This is just something to think about if/how it would be implemented in the next version of The GIMP.

Everyone agreed that this was something that could be implemented in 1.3, not in 1.2

3. Location of Flatten/Add Alpha Channel

14 Feb 2000 (2 posts) Subject: "flatten is too obscure"

People: Austin DonnellySven NeumannSven Neumann

Austin Donnelly wrote:

I just spoke to someone who tried to get rid of the alpha channel on their image before saving it (his gimp was pre-export stuff).

It's true that, even though I knew what I was looking for, it took me a while to find the flatten option.

The deceiving thing is that while "<Image>/Image/Alpha/Add alpha channel" exists, the corresponding "Remove alpha channel" is not on the same menu. This is deeply confusing. You have to go to the L&C dialog to get the "flatten" option. And only then, if you know what flatten does, will this make sense.

I suggest adding a "Remove alpha channel" option to the <Image>/Image/Alpha/ menu, which just calls the flatten routine.

Yes, I know this should be mostly solved with the export stuff, but there are still times when you want to get rid of an alpha channel.

Sven Neumann agrued that:

Since you do not add the Alpha Channel to the image, but to a layer, the <Image>/Image/Alpha/Add Alpha Channel menu is completely misguiding.

Add Alpha Channel should be in the Layers menu and, oh, there is Flatten in there too. Surprise, surprise ;-)

4. Proposed Optimizing The Print Plugin Initialization

15 Feb 2000 (4 posts) Subject: "Patch for print plugin"

People: Aaron Optimizer DigullaRobert L Krawitz

Aaron Optimizer Digulla posted a patch for the print plugin, and wrote, "The patch fixes an anoyance with the print dialog: If you have lots of printers (we have about 50 here), it takes *several minutes* to open. Fix: Just use lpstat -d -v (just list the names of the printers instead of checking if they are enabled; the information is discarded anyway). Later, when it becomes clear that we can use that info, we can reenable it again (including some kind of caching and a progress report which shows that Gimp is still doing something)."

Robert L Krawitz, maintainer of the print plugin, had some criticisms:

That patch AS IS isn't going to work. On my system (using PrintPro/CUPS), lpstat -d -v prints out in a slightly different format:

$ lpstat -d -v
system default destination: epson
device for epson: parallel:/dev/lp0
device for epson-big: parallel:/dev/lp0
device for foo: /tmp/out
device for null: /dev/null

Note that it uses "device" rather than "system". If you want to figure out how to make it work in general, go ahead -- it's a reasonable idea for 3.0.

In the intermediate term, we're considering getting rid of all of this stuff and using some kind of printer definition dialog, partly because we haven't found any robust programmatic way of determining the list of printers on the system and partly because it's reasonable for users to want to define virtual printers with different combinations of settings. Something like that's likely to make it into 3.2 (after having been in 3.1 for a while) as part of a general overhaul of the UI.

Aaron replied "Ok, then only the second word (for) seems to be stable (the third always seems to be the printer name). Any other systems around ?"

Robert L Krawitz finally rejected the patch as it stood. He replied to Aaron, "If you can test on Linux with a wide variety of different print systems (there are quite a few out there), different versions of Solaris and AIX, and if there's a BSD system running a SysV spooler, and demonstrate that it works on all of them, I will accept the patch. Otherwise, I won't accept this." He added in the same post, "It helps you, but at the risk of breaking other people and hence regressing from 3.0.6 and 2.0 (== Gimp 1.0). As the maintainer of the plugin, I consider this patch too high risk to accept. As I said, though, if you can arrange for system testing and prove that it works on all of them without being overly convoluted, I will consider accepting it, but not otherwise."

5. Bug Hunt In Perl Configure Script

16 Feb 2000 - 18 Feb 2000 (5 posts) Subject: "v 1.1.17 libintla error"

People: Tony WebsterRaphael QuinetMarc LehmannSHIRASAKI Yasuhiro

Tony Webster had a problem building Gimp 1.1.17 on his Mandrake box:

During the make process on my Mandrake Linux 7.0 machine of Gimp 1.1.17 I received the following error.

Running Mkbootstrap for Gimp::Lib ()
chmod 644
LD_RUN_PATH="/usr/local/lib/index.html" cc -o ../blib/arch/auto/Gimp/Lib/
-shared -L/usr/local/lib -l./../../../libgimp.libs
-Lirprefix/../../libgimp -lgimp-L/usr/lib -lglib /intl/libintl.a Lib.o
cc: /intl/libintl.a: No such file or directory

I noticed this says /intl/libintl.a but no /intl directory exists on my machine and nor should it. So to test my theory I created the /intl directory and place libintl.a in /intl and ran make again. This time make continued on fine.

I thought this might be a bug. With my little bit of programming skills, I would have no idea where to begin fixing this.

Raphael Quinet noted that "This is looks like a bug in the Makefile for the Perl plug-in in 1.1.17. If you do not want to edit that file, you can configure the Gimp with --disable-perl (but then you loose Perl) or you can create as root a symbolic link /intl pointing to the correct directory. This bug will probably be fixed in CVS soon, if not done already."

Marc Lehmann also replied to Tony, confirming that he'd found a bug, and adding, "I'll try to fix it. It's a tricky problem." SHIRASAKI Yasuhiro replied:

Only commenting $INTLLIBS out made all perl plug-in to crash. needs to be linked with libintl.

** WARNING **: wire_read: unexpected EOF (plug-in crashed?)
/usr/local/lib/perl5/site_perl/5.005/i386-freebsd/auto/Gimp/ Undefined symbol "bindtextdomain"

** WARNING **: wire_read: unexpected EOF (plug-in crashed?)

To SHIRASAKI's idea that needed to be linked to libintl, Marc Lehmann replied "That isn't that bad ;) Your patch to add intllibs was only added very recently. The problem is that automake is a very stubborn tool, which just means that solving these points of divergence between two systems takes some though and time :( I believe that I can fix that problem over the weekend, finally."

There were no more messages in this thread.

6. CVS Servers Not Updating

17 Feb 2000 (3 posts) Subject: "CVS Changelog"

People: Paul MelisSven Neumann

Paul Melis wondered "What happened to ChangeLog in CVS? The newest entry is dated January 26th (the revision date in my gimp/CVS/Entries says it is rev. 1.2137, dated Feb, 17th)." Sven replied that:

I guess you are having trouble with the anoncvs servers. There are four servers and I have the strong feeling that at least one of them is not updated any more for a couple of weeks now.

You may want to hardcode the IP of an anoncvs-server that works for you into your /etc/hosts file until this problem is solved.

Paul replied that "The faulty one is (, the other three seem to work fine."

7. Using Opacity Settings With Bucket Fill

17 Feb 2000 - 18 Feb 2000 (3 posts) Subject: "Opacity in bucket fill?"

People: Michael NattererJens Lautenbacher

Someone noticed that the "opacity" slider was missing from the Bucket Fill dialog box. The code appeared to still exist in gimp 1.0 and 1.1, and they suggested putting the "opacity" slider back into the dialog box. Michael Natterer said to "just deactivate the "Use Global Paint Options" button in the preferences dialog's "Interface->Tool Options" page. Otherwise the opacity as set in the brushes dialog will be used." Jens Lautenbacher suggested having "Use Global Paint Options" deactivated by default in the gimp, and having an "Enable Global Paint Options" option instead.

There were no more messages in this thread.

8. Problems Building From CVS

19 Feb 2000 - 21 Feb 2000 (5 posts) Subject: "pathsP.h"

People: Garry R. OsgoodSven NeumannSven Neumann Blue Lang

Blue Lang grabbed the latest CVS tree and found that it wouldn't build. There seemed to be a lot of missing files, and he asked if there was a problem with CVS. Garry R. Osgood suggested, "(1) tidy up through 'make distclean?' (2) Rebuild's through ' <your favorite configure preferences>' ( rebuilds configure, then runs the new configure for you) (3) make all. This synchronizes the configure script and makefiles with changes in the tree." He added that over the past few days, "there have been synchronization problems between various anoncvs servers - see 'CVS ChangeLog' thread," and concluded, "I think 'muck up' qualifies. Personally, I find it reassuring to tarball the work directory, blow it away, and let CVS build a new one from scratch, but that seems unnecessary in this case. Good luck."

Elsewhere, Blue asked if someone with good bandwidth could download a clean CVS tree and see if it would compile. Sven Neumann replied that "I'm pretty sure it builds. PathsP.h is not in CVS anymore, but there are new files and no dependencies to the old one. Update your CVS tree again. There is one of the anoncvs CVS servers out there that is not updated any more or is at least days/weeks behind the others."

9. Gimp Resolution Info; Printer Plugin Development Process

19 Feb 2000 - 20 Feb 2000 (12 posts) Subject: "gimp_image_get_resolution/gimp_image_get_unit/release timetable"

People: Robert L KrawitzMichael NattererSven NeumannSven Neumann

Robert L Krawitz wrote that he is "I'm experimenting with gimp_image_get_resolution(). It appears (in 1.1.17, at any rate) that whatever I set the units to I always get a resolution back that's expressed in dots per inch. Is this behavior correct? If so, did it work this way in 1.0 also? This is so I can investigate its use with the Print plugin."

Michael Natterer confirmed that the behaviour was correct, and added that there was no resolution info at all in 1.0; he also asked, "BTW, do you really want to support 1.0? It may be quite hard to make use of the help system and the libgimp ui stuff (i.e. sizeentries which may be useful for the print plugin) if you want to keep the print plugin running with 1.0..." Robert replied, "Well, thus far we've had very little trouble supporting 1.0. Even the configure script works properly. 1.0 is still the stable release of the Gimp." Sven Neumann objected, "I really don't understand your development cycle. We are approaching the 1.2 release but you insist on keeping the code that is going to ship with 1.2 compatible with 1.0. At the same time you start a new unstable branch heading towards a future you know nothing about yet. Why don't you put some effort into making the print plugin that ships with 1.2 a nice and featureful one? Adding new printers and other sophisticated stuff is probably a bad idea, but overworking the UI and supporting resolution info are things that should be addressed right now." Robert explained:

Well, we're at least nominally in feature freeze for 1.2. I've seen more than enough projects boondoggle because people try to add more stuff in at the last minute and thereby delay things that I don't want to cause that to happen here. If we can ship 3.2 to high enough quality standards sufficiently far in advance of Gimp 1.2 that's fine; if not, I don't want to destabilize things further.

There has been a lot of talk on this list about not wanting to make major changes to further slow down 1.2. I happen to agree with that position. Gimp 1.2 needs to ship (IMHO), even if it isn't perfect, so we can clear the decks for 1.3. And while the print stuff is a plugin, it's close enough to core functionality (every bit as much as, say, .tif or .psd) that it needs to be responsible.

Despite this, if the gimp release management team were to announce that the Gimp 1.2 release is now scheduled for August (6 months), I would change my plans and aim for a 3.2 (or 4.0) release for early summer or thereabouts, with the GUI rewrite and all that. But that's not the announced state of affairs right now; it's claimed to be a fairly short term affair.

I didn't initially plan on 1.0 compatibility at all. However, as soon as the driver hit the street, a lot of people started asking about 1.0, and someone submitted a simple patch that worked. Whatever's going on in Gimp development land notwithstanding, there was a lot of demand to print to 3 year old printers (as opposed to the 5 year old printers that 2.0 supported). The Stylus Photo EX is now 2 generations behind the times, but right now it's about the only even remotely photo quality printer that works, and there are a lot of them around, and people really want that. If it's going to be another 6 months to a year before Gimp 1.2 comes out, then we really do need to support 1.0 with the new printers and the UI improvements that we already have. If we're a month away, then 1.0 support is less critical, but there's also no time to do serious UI work.

As for the matter of what's featureful, I guess it depends. If you have an Epson Stylus 740 or a Canon printer that isn't supported with the current release, I would venture to say that that functionality is a lot more important than the resolution info stuff, which after all does have an easy workaround and which I'm not even convinced is really that critical from anything other than a consistency standpoint. We really need core printers like the Stylus Color 740 and the Canon BJC series to work, and having really good printers like the Stylus Photo 1200 (or better yet, the 1270) work will go a long way to boosting the Gimp as a high quality graphics tool. There are already enough complaints that Linux doesn't support modern hardware, and those really need to be addressed or the Gimp will be useless for people who really want to do high end stuff such as photo manipulation.

Spinoffs such as the Ghostscript driver are probably even more important, for exactly the same reason.

Certainly the vast majority of comments we've received concern operation of specific printers rather than specific UI features, and the UI features I've heard the most about are things like CMY gamma (individual channels) and such that really matter for printing.

What WOULD help us get to 3.2 faster would be for more people here to check out 3.1 and the UI changes we've already made and give us feedback on that, and for the Gimp team itself to give us a schedule to help us plan our release timeframe. Better yet, why doesn't someone who wants this resolution stuff that badly code it up and submit it, or join our project?

There was no reply.

10. Compile Problems On Solaris 8

21 Feb 2000 (3 posts) Subject: "Errors compiling Gimp 1.1.17 on Solaris 8."

People: Ludovic PoitouMichael NattererSven Neumann

Ludovic Poitou was getting errors compiling Gimp 1.1.17 on his Solaris 8 machine with the native compiler. He explained, "In plug-ins/common/ both gauss_iir.c and gauss_rle.c fail compiling because of G_MAXDOUBLE." Michael Natterer replied that "G_MAXDOUBLE might be *slightly* too large as a blur value. I'll change it to GIMP_MAX_IMAGE_SIZE (which is still quite large but will compile :-)" . Sven also noted that it was "Fixed in CVS together with a few more places that had the same problem. Thanks for the report. If you have access to CVS, please update your tree and give it another try."

11. Improving Locale Support

22 Feb 2000 - 23 Feb 2000 (30 posts) Subject: "PROPOSAL: New i18n solution"

People: Daniel Egger

Daniel Egger posted a huge message about how to solve the i18n problem:

as you might know that gettext solution works quite nice for GIMP itself but may cause trouble with plugins. To circumvent the problem that every plugin must have it's domain registered within the GIMP source, I'll offer you a new idea here:

0. Foreword

Basically we can't get away from gettext and switch to a better system (which would have to be written first, too) that short before a release like at the moment. Thus my goal was to change as little as possible. Like you'll see, we'll just have to add a line to every plugin outside the GIMP distribution to make this work; everything else stays the same like it is now, even the catalogs remain untouched.

1. Ideas

1.1 The config file

The current system is a very static one i.e. nothing can be changed neither without the sourcecode nor after compilation. What we need is a dynamic system to remove that deficiencies. A good way to bring some dynamic into a system is to make it configurable for example by having a config file. This configfile of course shouldn't have to be modified by an editor but automatically by the GIMP resp. libgimp.

1.2 Plugins with libgimp

To get this information in there we'll provide a funtion call in libgimp which registers the domain from the name and path the plugin CAN provide. If the domain hasn't been registered yet it'll its way into the configfile

1.3 The GIMP core

The GIMP uses the information from this file to bind the necessary catalogs to itself. To actually use this bound domains we'll have to provide a function which won't look up a message in one catalog but recurse through all of them. This function will replace the gettext call just in places where the GIMP would lookup a menuentry which is sometimes not in its own catalog.

2. Implementation

2.1 The configfile

Like all other configfiles this one will stay in ~/.gimp-<Version>. The first line contains ":gimp" to ensure that no one messed up this file. The next lines contain the name of the domain, a withespace and the location of the catalog. One catalog per line.

2.2 Plugins with libgimp

For the plugins we'll have two new functions in libgimp/gimpdomain.c which have the selfexplaining prototypes.

gimp_domain_add (gchar *)
gimp_domain_add_with_path (gchar *, gchar *)

Every plugin may register a domain but don't has to necessarily. The functions call another static one which checks whether the files already exists and whether the domain is already registerd. If so it won't be registered again else it will.

2.3 The GIMP core

GIMP will call initgettext() at startup which will initialise i18n if compiled with it and setup a default (and fallback) domain "gimp" and every domain that it'll read from localerc.

Every occurence of gettext which had been used to translate menunames will be changed to gimpgettext which consists of a loop which checks for a possible translation in all domains which were read from localerc. At the end GIMP'll call freegettext() to clean up everything.

3. Conclusion

This idea will cirumvent most of the problems which gettext alone just can't deal with. It's little and as such not very likely to introduce many new bugs. It would allow us to ship GIMP 1.2 with the possibility to add plugins which will also benefit from localisation without any hassle.

Patch against current CVS is appended. Please feel free to contribute further ideas and to comment this stuff.

There was a fairly length implementation discussion, with some concensus that the ideas were good.







Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.