Gimp Traffic #19 For 31 Mar 2000

• There seems to be a problem with the big titles. As you can see at http://www.home.unix-ag.org/simon/gimp/GimpUserInstallation.png the title of an page gets cut off (Gimp CVS from Sat Mar 25 02:01:18 CET 2000 ).
• The dialog is quite huge, it does not fit on a 640x480 screen completely. Do we need to fix this?
• Personally I dont like the orange color. I prefer blue, but this is personal preference. I tried an alternative layout (with Gimp - not C :-) (moving Wilber to the right, blue color) and created another Wilber-Icon with a helmet on to indicate that there is real Work going on :-) You can see a pseudo-screenshot at http://www.home.unix-ag.org/simon/gimp/GimpUserInstallation2.png
  The XCF of the new Wilber is available at http://www.home.unix-ag.org/simon/gimp/wilber_work2.xcf.gz

1
xtra/perl-fu/bricks -> xtra/perl-fu/paterns/bricks
------------/Random Art ->------------------/Random arts
Does this really have to be separated ?

script-fu is about scripts, that means files translated on-the-run for example perl, scheme, python, basic (yuck) and so on...

which in general should be all in one - I suggest to rearrange the menu connected with scripts (to all translators - SORRY FOLKS 8-)

2
scripts which need to be repaired, they work but they don't register (in menu):

• fire
• frame_filter
• frame_reshuflee

these scripts don't work at all:

• border
• gouge
• map_to_gradient init_progres
• prep4gif
• image_tile
• burst init_progress
• home-pagelogo net caalback
• gimp-make-img-map net callback
• blowinout now, what does this one do, really ?

these are not getting copied to $gimp_dir

• billboard
• feedback
• these don't work because of the lack of perl 5.0005
• PDB
• Visual
• parasite-editor

In the above text some plugins are in a form of filenames or procedure names

3
Is "2x2 Blur"(perl) and "Blur"(C) not the same, if so then why double the same plugin (and keep your hands away from the C version)

4
after Gimp crash, and this is quite often these days:( the units and many other settings disappear. If we happen to have small HDD (or quotas) and we are running out of disk space it behaves the same way.

Proposition: we save all the configuratoin files in a safe way.

cp old new
write to new
if no problem {

mv new old

} else {

rm new mesage: file save failed

}

;-)

5
When I click the arrows in image space (navigator or so) I get: initial_sub_region:: error :: src->w * (src->bytes + 1) > 512

6
Ununified Gimp interface

• tools
• filters

6a
What resolution is Gimp written for ?? As I presume many people start with 640x480 and is happy with 800x600(15") not 2millions x million ;-)

7
Lack of localization for scheme scripts

8
I don't think you can remove tips (many applications under windblows:) have help and tips and that does not seem to be a problem

9
Why colour brushes can be animated and grayscale can not ? (Telling me to stop using the colours is not the answer:).

No. In an ideal world, Logo scripts would be in Xtns/Logo/whatever, not seperated by language-isms. Nobody should need to memoize wether a plug-in is implemented in c, python or scheme to use it.

IMHO, the perl way (group plug-ins by function, rather than by implementation language) is the right way.

Reorganization efforts in that direction will certainly clean up the menus.

5) Huh? Could you please try to explain that in more words? Eventually I might get what you are talking about then.

6) More details? There's a clear distinction between tools and filters. We try to make the dialogs as compact as possible. A lot depends on the font size you use however. For small displays, I recommened not to change the gtk+ default size (or even choose a smaller one). Of course it's not always easy to keep the dialogs small enough for all screen resolutions. If you think a dialog is excessively large, please write a bug-report (and please be a little more verbose than you did here).

7) We are working on this. In fact, the menu paths already are internationalized and the rest of the GUI is prepared for i18n too. All we need is a parser that extracts the translatable strings out of the script-fu-register calls in the scripts. The rest of the infrastructure is already present.

8) Huh? You can disable tooltips in the Preferences!?

9) This is definitely a design mistake in the animated brushes. We will however not change this before 1.2.

I see, that Gimp can be crashed very easily when trying to use multiple tools at the same image/layer. Michael adressed this: from the changelog:

2000-03-25  Michael Natterer  <mitch@gimp.org>

        * app/cursorutil.[ch]: new global variable "gimp_busy" which gets
        set/unset whenever busy cursors are added/removed.
[...]
        Here starts the ugly workaround which simulates something like
        locking. If it works, it will close lots of bugs, if not, it's
        easy to remove again.

        So far, I didn't find strange side effects but Gimp is told to be
        a complex program :-) Please test this.

Well - unfortunately this disables "user multitasking" with working on multiple images. Admittedly I dont do this too often, but sometimes it is nice to paint something while waiting for a big image to rotate. (just tested - multiple plugins do work! :-)

Is there any chance to do this on an "per image" base without hazzeling too much? Or - if this is too hard to implement - do you think that this limitation is better than crashes which could be avoided if the user knows that parallel operations on an image will fail and result in data loss?

I proposed to add per-image locking a while ago, but apparently this wasn't too well liked. I'm can't remember why.

There are 2 tricky parts (as far as I can see):

1. plug-in.c needs to take out an image lock when starting a plugin operation, and release it on normal (or equally importantly) abnormal plugin termination.
2. what happens when acquiring a lock fail? Do you queue the operation up on the lock (hard) or do you fail it (easy)?

I think, proper locking is among the first things that should go in Gimp 1.3. However, it may be a little bit late for 1.2 :-(

What Im thinking about is: Every user action starts in the image window. When we prevent

1. clicks in the image to take effect
2. selection of menu items (graying out?)

if this image is "locked" we have a lot of potential crashes fixed. We could even give some sort of feedback through the cursor.

Well, when a script or plugin randomly accesses the locked image then this is bad luck, but I think this should not happen too often.

The way described above eventually could be handled inside the callbacks. Mitch: Do you see a chance to get it working this way? Is this reasonable?