[CinePaint] strange handling of SIGTERM

Greetings to all Cinepainters out there,

I succeeded in building Cinepaint on my Ubuntu laptop for the first
time, after a few failed assaults spread over a couple years. This
time, I had no problems at all -- just ran ubuntu.sh and got it
running a few minutes later. Instant gratification followed, lasting a
couple days or so. I think I am even beginning to to understand color
management and other fabulous things.

I've got a few small issues, and I am not sure whether they have
something to do with the way I built it (totally mindlessly), or they
are features.

1. It doesn't want to die. It responds to sigterm by looping and
saying "sigpipe caught".  It seems as though the "script-fu" bit dies
first and makes the parent process wait on a broken pipe. And the
parent seems to be detached from the shell it was started from, so it
doesn't any further signals from the shell. I have so far found only
two ways of killing it: from the parent shell by its job number (it
ignores SIGTERM, but it can be stopped and then killed). Another way
to kill it is by deleting its main window through the GUI (gnome). A
somewhat messy consequence of this behavior as the when my Xorg dies
(and it does that often, owing to a perpetually buggy nvidia driver),
or when I log out, cinepaint remains looping in this half-dead state,
wasting 100% CPU. I just got two of them do the same thing, having
overlooked the first instance.

2. Image windows ignore button4, button5, and whatever other scrolling
and zooming events are typically used in graphics apps.

3. While zooming in or out with '+' or '-', the window does two
strange things: (1) it grows; and (2), it re-positions itself. I end
up chasing the window all over my screen. I wonder whether this
behavior is optional and can be turned off.

4. I read that I can change menu keyboard actions by entering the
desired key combination while a menu item is selected. The labels in
the menu do change, but the new key codes are not recognized. And they
don't stick; the next time I run it, they are gone. I'd love to be
able to replace Alt wih Ctrl in most menus, because my short fingers
don't stagger too well. Also, should I succeed in building Cinepaint
on my mac, it has only one Alt key.

5. Many menus don't have any key codes linked to them. Is that because
they never had, or did something fall through the cracks while I built
it?

6. I tried to see whether tools respond to keystrokes. The text tool
responded to T all right. Nothing else that I am used to in Gimp
worked; I got this message in response to everything I tried, except
for selection-related commands, which work fine:

Error: Unable to set state for menu which doesn't exist:
<Image1>/View/Toggle Rulers

7. I feel I ought to put this question in a separate post, because it
is so different from everything I've observed so far, and it's by far
the most important one. It may be that I haven't really begun
understanding color management. Whatever I tried to do during the last
couple days left me with a suspicion that my display profile is
applied twice. First when it is loaded into my display's LUT. And the
second time, when Cinepaint opens my image. The reason I believe so is
because the same image looks very different when I view it with a
non-color-managed tool. To be exact, it looks right in evince, for
example, which is not color-managed. To make sure I knew what's right
and what's not, I took a shot of a reflective IT8 in direct sunlight,
saved it into an sRGB tiff with ufraw, using my camera's internal
matrix (which is a more trustworthy calibration source than any
profile I managed to produce so far), and when I view that in any
profile-agnostic tool on my newly calibrated screen, it does look
right. Which means, I believe, that Argyll did a great job, and that
my camera isn't too bad either. Now, when I open that image in
Cinepaint (regardless of the profile assigned), It looks too bright
and too red -- which is what I would expect from my current display
profile, if it were applied twice (I know the direction and
approximately the amount of change it effects, from the uncalibrated
state,  and the change I observe in Cinepaint is in the same
direction, and by about as much).

Another curious observation is that when I open my raw file with
Cinepaint, it does look right, but only until I try to something
useful to it. I cannot save it or make any changes, or add a layer, or
copy it to another image; whatever I do to it make it look wrong. It
becomes too dim and too blue.

Finally, the most bizarre thing I observed: I pretended to ignore all
the circumstances leading to this apparent double-correction and did
some curve editing in Cinepaint to force image back to where I would
like it to be, and I did that in Lstar-RGB (although the difference
would be only slight if I did it in sRGB; then I saved it and opened
it in Krita and a number of other color-managed tools. It looked the
same in all of them. It even looked the same in Gimp, after conversion
to sRGB that Gimp offers when it sees an unknown profile. Without such
conversion, the image looked too blue and too dim. I was encouraged by
that, and decided to send the image I edited in Cinepaint to a print
shop. If it looks right in all those color-managed viewers, why
wouldn't it print well? The shop's proprietor got back to me saying
that the image is uncomfortably blue, and it didn't matter whether he
kept Lstar-RGB or  converted it to sRGB.

There is something profoundly wrong in my toolchain, because when I
consider all these effects together, they add up to something like
Escher's straircase. Does any of this seem familiar to anyone? Is
there a rational way of sorting it out?

Thanks,

--Gene

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july