Gimp Traffic #13 For 11 Feb 2000

By Alex Harford

Table Of Contents


Yosh announced that GIMP 1.1.17 is out:

Mailing List Stats For This Week

We looked at 311 posts in 968K.

There were 74 different contributors. 31 posted more than once. 40 posted last week too.

The top posters of the week were:

1. GIMP UI Inconsistencies

1 Feb 2000 - 5 Feb 2000 (6 posts) Archive Link: "Some UI inconsistencies and a patch...."

People: Daniel EggerMarc LehmannMichael Natterer

Daniel Egger posted his fixes for some Gimp menu problems:

  1. The "Settings" in the preferences Dialog wasn't in everything and is useless nevertheless because a preferences dialog is supposed to contain settings...
  2. Some tools had a "Tool" in the options dialog and some not. Since all tools are tools and people know what tools are, we don't need to call some tools additionally tools.... :))
  3. The optiondialog of the tools is obviously a option dialog and nothing else so removing the "Option" is sensible and matches the behaviour of the professional programms....

Michael Natterer wrote that he had also just applied a patch that fixed some of the same things, but will add the changes to the Preferences dialog.

Marc Lehmann had some criticisms:


1. "Category New File"

Looks IMHO much worse than the existing:

"Category New File Settings"

2. Same thing here. Just because all tools are tools there is no reason _NOT_ to display this.

3. Same here... Just because all these dialogs are option dialogs there is not reason not to display this fact.

Daniel disagreed:

Not really, you have the word "Preferences" just a few mm above it. Also there was some inconsistency: The category "Monitor Information" was a settings dialog anyway but it had no "Settings" in its name....

Well, we could have add the word "Tool" to all tools the other way round but that's unprofessional; you don't call every Mercedes "Mercedes Car", do you? You know that Mercedes produces cars as you know that a pencil is a tool and in a toolbox every item is a tool.

There's no need to tell the user what she/he's seeing if it's obviously.

Uhm, I guess like the idea of having window titles that tell you what you should see, so why no "Save File Dialog" or "Preferences Dialog". That no good UI design, in fact if you look at the comercial competitors of GIMP you'll see that they don't do this either and surely this gives a more professional impression...

Marc continued his explanation of why he disagreed with Daniel:

The problem is that I know that every thing in the toolbox is a tool, but I do not know that a givne dialog belongs to such a tool unless it is marked as such.

The reason nobody calls it a Mercedes car is because you can see it. Windows look the same, so you need other things to differentiate between them.

I would rather like _more_ information displayed in the title than is already. For example, if I open a Save As dialog window and answer a phone call, it is not obvious which image you wnated to save (as this isn't displayed anywhere).

Daniel replied, "YES, you finally got it! So let's make it visible what image you are about to save instead of underlining the point that this window is a dialog (which everyone can see).... That is sensible UI design."

2. Documention Source Code

1 Feb 2000 - 2 Feb 2000 (9 posts) Archive Link: "Documenting the source?"

People: Daniel EggerSven NeumannSven Neumann

Daniel Egger once again started the discussion by saying:

Having no real documentation of the sourcecode is really a burden when searching for bugs. Do you agree that having a documentation would be fine? I'd like to introduce a in-source-documentation which an extractor program could use to make a TeX or HTML file of it.

Using javadoc like comments we'd always have a specification of a function handy without having to guess the sense.

Sven Neumann replied that:

We have already brought up this issue lately and I think the conclusion was that we try to add documentation for libgimp before 1.2. Most certainly we will use gtk-doc with comments embedded into the source. Marc volunteered to write the necessary scripts to convert the info out of the PDB.

This would make the visible (to the outside) parts of The GIMP documented and will make life much easier for plug-in developers.

We should give Yosh some time to do the 1.1.16 release before we start to mess with the build, but I'll try to have a look into adding the necessary framework then.

Daniel Egger had some more questions for Sven:

What characters does gtk-doc use to introduce a comment? I like the idea of having javadoc like comments i.e. /** */ with some special tags because there are several programms out their which make beatyful documentation out of this and it's quite a standard solution...

I volunteer to do some of this documentation... I have to get the sense anyway... :))

Sven gave an example for the documented code, and added that "The good thing is that gtk-doc checks that the documentation and the source are in sync and it creates DocBook SGML that can be used to create nicely linked HTML. In the example above all gimp-specific types and enums (GUnit, GimpSizeEntryUP, GimpSizeEntry) would be linked to their declaration. But I guess you have worked with the glib and gtk+ reference manuals before and know how the output looks like."

Daniel explained why he liked Javadoc:

Hm, yes, but the gtk+ manual is not quite what I had in mind. I thought of really in-source-documentation and looking at your example code I think you had the same in mind. But I would like to use a standard not a new solution, therefor your examplecode doesn't match my thoughts. Defining the documentation of the parameters directly by giving every one unified metatag is very restricting. Javadoc like sourcecode has a better approach.

There are at least a few dozen programms which can extract this and export them to at least that number of formats. Have a look at doc++, a very cute program to generate documentation...

Some other people suggested other programs that could be used, but it was agreed that gtk-doc would be used.

3. Slow Loading Of Large Images / Tile Cache Size

2 Feb 2000 - 5 Feb 2000 (20 posts) Archive Link: "Performance"

People: Martin WeberTom RathborneSven NeumannElan FeingoldDaniel EggerSven Neumann Raphael Quinet

Martin Weber posted some interesting benchmarks:

Here some performance tests on an Intel Celeron 333 with 128 MB: BMP file, grayscale (8-bit), 10000x7500

loading with ImageMagick 5.1.1: 20 min
loading with GIMP 1.1.15: 10 min
loading with Photopaint 8: 1 min 39 sec
loading with Photoshop 5: 14 sec

saveing with GIMP 1.1.15: 2 min 25 sec
saveing with Photopaint 8: 23 sec
saveing with Photoshop 5: 11 sec

Tom Rathborne had some suggestions for Martin:

What do you have your tile cache set to? How much RAM is actually available to the GIMP? ... more details would probably help.

My Dual PII/500 with 256MB of RAM and a 7200RPM IDE drive and 128MB tile cache loads big TIFFs in seconds.

Martin provided the stats, "I use SuSE Linux 6.2. I have 128 MB RAM. I use the default values for tile caching. I have a EIDE IBM 6,4 GB and 10 GB. I use on both a 128 MB partition as swap."

Everyone agreed that Martin should increase his tile cache size.

Sven Neumann then asked:

Shouldn't we increase the default for the tile_cache_size? GIMP was shipped with the default of 10MB years ago. Memory is cheap nowadays and I guess we can expect the average user to have more RAM available. I'd suggest setting it to 32MB.

I want to present an older idea once again since the discussion about the tile_cache_size is bac alive. I propose to add a dialog to the user_installation step that lets the user specify the tile_cache_size and the swap directory. Of course such a dialog would also have a few short sentences explaining the importance of these settings together with hints for a good choice.

Elan Feingold suggested some ways at setting it instead of guessing:

Instead of guessing at fixed amounts, why not:

That way, the default the Gimp ships with will work with all systems, and also on a given system if the user dumps more memory in, the Gimp will automagically have better performance.

Arcterex cautioned trying to guess tile cache size, "I think that this was discussed some time back and the conclusion was that if you have 5 users on your system all using gimp and each using 50%... well, you see where that could be a problem. "

Raphael Quinet also warned that these methods would have to work for all platforms, Solaris, Linux, Windows, OS/2, etc.

Daniel Egger noted that "In that case you could adjust the value manually. But bear in mind: If you have 5 users manipulating big pictures via remote X you will have other perfomance problems than too little memory..."

Other people asked about how it will work on mutli-user systems. Sven replied that "I thought about making it dependant on whether the sysadmin put a default value into the gimprc_user (which is the file that gets copied into the users .gimp directory later. It should be trivial to parse this file during the user_installation step. If the tile-cache-size is set, use the value and skip the extra dialog. If we document this even sysadmins that use binary packages have a chance to set a default value globally."

There were no more messages in this thread.

4. Key Modifier Changes in Fill Tool

4 Feb 2000 - 5 Feb 2000 (9 posts) Archive Link: "Edit Fille behaviour change"

People: Tom RathborneZach BeaneFederico Mena QuinteroStanislav Brabec

Tom Rathborne wrote to say that he noticed a new CVS entry:

Fri Feb 4 18:27:16 CET 2000 Stanislav Brabec <>

* app/global_edit.c: edit_fill with foreground, not background.

Checked the code. Looks like 'Fill' now uses the foreground. So I recompiled the GIMP. Indeed, the changes do what it says.

Fill (by default Ctrl-.) has filled using the background colour in the GIMP for as long as I can remember. I don't think it's a bug, and making this change will suddenly render all of the GIMP books completely obsolete! Ok, so GIMP 1.2 will make the books obsolete anyways... but changing such a basic core UI thing seems like a bad idea to me.

Zach Beane wrote that:

I agree. I have grown very accustomed to the existing behavior, and I don't think it should be changed.

I know it hasn't been customary in the past, but I think such a user-visible change should be discussed a little bit.

Federico Mena Quintero asked what Photoshop does, but several people said that it doesn't really matter what Photoshop does. The Gimp has a large enough user base that it can use it's own methods rather than following Photoshop.

5. Removing the Pencil Tool From the Gimp

5 Feb 2000 - 6 Feb 2000 (7 posts) Archive Link: "Removing pencil?"

People: Daniel EggerSven NeumannTuomas KuosmanenSven Neumann

Daniel Egger yet again started the conversation with this message:

I think it's time to remove that useless pencil before the release of the magic version 1.2. Did anyone use it in the last time? It contains no functionality that paintbrush doesn't have except of hard edges (anyone needing that "feature"?)...

Anyway: This is up for discussion on this list. Quite a lot people I know think it's useless but maybe you don't think so. :)

Sven Neumann had a compromise:

It is a very important feature, believe me! But the pencil can easily be merged with the Paintbrush by adding a "Hard Edges" option. This will add all the goodies the paintbrush has (like gradient and fadeout) to the pencil tool for free.

I'm all for removing the Path Tool, the Xinput Airbrush and and merging Pencil and Paintbrush. If I counted correctly this would reduce the number of tools to 24. This is a perfect number of tools since 24 % [2|3|4] == 0 which means we always get a nicely layed out toolbox.

Daniel Egger replied that "Yes, if you appreciate. But the makes the eraser rather useless... We could add the eraser features, too and use the same codebase for these 2 tools."

Tuomas Kuosmanen replied that he liked the Pencil Tool:

Some minor projects like Gnome icons come to mind..

I use the pencil every day. And a _lot_. It is way sharper than the paintbrush even with the 1x1 brush.. I use it as an ultra sharp tool with low opacity to do microscopic stuff on icons :)

He explained that he liked to switch between the Paintbrush as the real tool, the Pencil for fine touch ups.

Most people agreed that these can be left in 1.2, and for Gimp 1.3 some significant changes will be made to the Pencil/Paintbrush tools.

6. Gimp Crashes When Setting the LANG Variable

9 Feb 2000 - 11 Feb 2000 (4 posts) Subject: "gimp && i18n == segfault"

People: Marc LehmannSven NeumannDaniel Egger

Marc Lehmann noiticed a bug on startup:

Since about two weeks, setting LANG to any value results on a segmentation fault on startup.

Program received signal SIGSEGV, Segmentation fault.
0x4015822d in g_strdup (str=0x81e8273 "help_page") at gstrfuncs.c:56
gstrfuncs.c:56: No such file or directory.
(gdb) bt
#0 0x4015822d in g_strdup (str=0x81e8273 "help_page") at gstrfuncs.c:56
#1 0x40107f18 in __DTOR_END__ ()
#2 0x88b4b30 in ?? ()
#3 0x42207265 in ?? ()

Daniel Egger replied that he could not reproduce this, but it would be helpful if Marc could recompile libgimp with debugging information.

Sven Neumann replied that other people were having the same problems. He has introduced a patch that should fix this problem.

Marc Lehmann replied the next day, "Your recent patch completely fixes the problem for me."

There were no more messages in this thread.

7. Alignment of Items in Toolbox

9 Feb 2000 - 10 Feb 2000 (6 posts) Subject: "Move help menu item to last-on-left not first-on-right?"

People: Nick LambMarc Lehmann

Nick Lamb had a suggestion for the list:

I'd like to change the Toolbox to do this:

.____________________. or ._______________. or .____________.
| File Xtns Help     |    | File Xtns Help|    | File Xtns H|

rather than (as now) this:

.____________________. or ._______________. or .____________.
| File Xtns     Help |    | File Xtn Help |    | File  Help |

Can people please tell me why (technical or HCI reasons) I shouldn't do this, given that we don't HAVE to use GTK+ features just because they are there. Comparison with other image editing apps (especially on Unix/Linux) is appreciated, flame wars are not.

Ideally, of course, GTK+ would do *something* when menus are not given sufficient width allocation, but that's not fixable for Gimp 1.2.0 release. Right now what I have most resembles the left-most bad case above, and it's impossible to choose Xtns(!)

Marc Lehmann wrote that other apps place the Help menu in the same position, and does not see any reason to make the Gimp different.

Nick explained his position further, "Ah, that wasn't clear from my diagrams? GTK+ draws space either side of a menu item, so the Help menu can cover over Xtns, making it useless and forcing me to have an otherwise unnecessarily wide toolbox. If the Help menu was in the same SET of menu items as File, Xtns (ie on the left) it would never overwrite them, and therefore use less space. Also if we're going to have casualties from manually shortened toolboxes, Help is much less useful than Xtns, because its key features are duplicated elsewhere. Hmm... I should have written that before."

Most people agreed that this was a shortcoming of GTK+, and this would have to be changed in GTK+ before changes to the Gimp were made.







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.