Gimp Traffic #13 For 11 Feb 2000

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....

Your:

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.

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...

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).

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.

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.

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... :))

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...

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

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.

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.

Instead of guessing at fixed amounts, why not:

• Detect how much memory the user has.
• Pick a reasonable default in terms of percentage (say, 50%).
• Let the user change this default, also in terms of percentage.

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.

Fri Feb 4 18:27:16 CET 2000 Stanislav Brabec <utx@penguin.cz>

* 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.

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.

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. :)

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.

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 :)

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 ?? ()

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(!)