When you change a settings in Preferences which requires a restart of
GIMP, the current list was pretty ugly. I am still not fond of the popup
but at least now the list formatting is slightly better:
- Use a unicode bullet point character in UTF-8 encoding (since
gtk_message_dialog_new() expects UTF-8 input) on each list element,
instead of just writing them without any kind of formatting.
- Use the "nick" of the changed config, not the name. The "name" is an
internal string which is really not meant to be viewed by people,
while the "nick" is more like a short human-readable name or title,
exactly what we want to show here.
Some strings might be generated during query() call, in particular all
strings related to procedure parameters. The core will only know the
localized version at query() time, so you could end up in situation with
the core showing you the wrong language. This can be reproduced in the
Procedure Browser when it shows localized procedure data: when you
change the language and restart GIMP, if the plug-ins aren't re-queried,
then it will still show the localization of query time.
Note that it doesn't matter on plug-in side, i.e. anything in the run()
call is properly localized, included the plug-in GUI using the same
procedure parameters for widget labels or tooltips. Only the "vision" of
the core is stuck at what it got when the plug-in was last queried, and
until the next update of the plug-in.
Small text tweaks done too:
- Some question marks removed to be more consistent in the tooltip
style.
- The "save-transparent" only applies to *completely* transparent pixels
(not partially transparent).
Let's not try to align anymore the label text with the value (numbers
inside the GtkEntry) text. Our previous offset computation was wrong
anyway, but even correctly aligning the text, there could be cases where
the label's actual font was bigger than the number's font.
I had the case with GIMP set in Korean. The number text was 11-pixel
high but the Hangul text on 16 pixels in plug-ins using a GimpSpinScale,
most likely because the font used for numbers didn't have Hangul glyphs.
So we ended up with very ugly scale title on the bottom of the widget,
even out of the progress area. Instead, we just make sure that the label
is exactly in the vertical middle of the widget, disregarding the entry
layout's offset.
Also changing "RGB->YUV" by using a real Unicode rightward arrow encoded
in UTF-8 since GTK functions (such as `gtk_widget_set_tooltip_text()`)
explicitly uses UTF-8 encoded strings as argument. This renders much
more nicely than an ASCII-made arrow.
As mentioned by Massimo in issue #6618, part of the problem there is an
integer overflow when using large size images when computing the offset
in pixels.
Let's fix our part of the problem by casting to guint64.
Besides that, also use casts to correctly compute progress for very
large images.
So it turns out that the "notify::src-drawables" property signal in
particular can happen during gimp_paint_tool_paint_interpolate() called
from gimp_paint_tool_paint_thread(). Though the function
gimp_clone_options_gui_update_src_label() was run in the main thread in
simple cases, being called this way through a paint thread happens when
very quickly changing the source while painting, which is what Aryeom
does (when I see her using the clone tool, she would sometimes change
the source very quickly several times in barely a few seconds).
Yet GTK and GDK calls must not happen in non-main threads. It used to be
acceptable when protected with gdk_threads_enter|leave() calls but doing
this is deprecated. The now sanctioned method is to call the GTK code in
an idle function since these are guaranteed to run in the main thread.
This was most likely explaining why crashes could quite randomly happen,
though I'm not sure why I never had those (even though I could reproduce
the GTK calls happening in non-main threads, but without crashing GIMP)
and why Aryeom gets these much more often suddenly. Maybe some recent
dependency change which would trigger these more easily or other
context-dependant changes (as most non thread-safe code, bugs and crash
often happen in race conditions, so are harder to reproduce reliably)?
We already had import support through littleCMS. We now use fully
babl/GEGL which makes our code more straightforward and identical,
whichever the input format.
The export support is totally new. It comes with a checkbox to propose
selecting CMYK export and a label displaying the CMYK profile which will
be used.
Now this whole implementation has a few drawbacks so far, but it will be
a good first sample for future CMYK-related improvements to come:
* The export profile I am using is what we call the "simulation
profile" from the GimpColorConfig. This corresponds to the default
"Soft-proofing" profile as set in Preferences. In particular, this is
not the actual soft-proofing profile for this image which might have
been changed through the View menu because this information is
currently and unfortunately unavailable to plug-ins. It is not the
"Preferred CMYK Profile" either, as set in Preferences.
TODOS:
- We really need to straighten the soft-proof profile core concept by
storing it in the image and making it visible to plug-in.
- Another interesting improvement could be to create a
GimpColorProfile procedure argument which would be mapped to a color
profile chooser widget, allowing people to choose profiles in
plug-ins. For an export plug-in in particular, it could allow to
select a profile different from the soft-proof one at export time.
* When we export, if no profile is choosen, babl will use a naive
profile. It would be nice to store this naive profile into the JPEG if
the "Save color profile" option is checked (same as we store a generic
sRGB profile when no RGB profile is set).
* When we import, we just import the image as sRGB. Since CMYK gamuts
are not necessarily within sRGB (some part of the spectrum is usually
well within, but other well outside), other than the basic conversion
accuracy issue, we may lose colors. It would be much nicer to be able
to select an output RGB profile. Optionally if we could create a RGB
color space which is made to contain the whole input CMYK profile
color space, without explicit choice step, it would be nice too.
* I am using babl's "cmyk" format, not the expected "CMYK" format.
"cmyk" is meant to be an inverted CMYK where 0.0 is full ink coverage
and 1.0 none. Nevertheless when loading the resulting JPEG in other
software (editors or viewers alike), the normal CMYK would always
display inverted colors and the inverted cmyk would look fine.
Finally I found a docs from libjpeg-turbo library, explaining that
Photoshop was wrongly inverting CMYK color data while it should not.
This text dates back from 1994, looking at the commit date which
introduced this paragraph. In the 28 years since then, could this
color inversion have become the de-facto standard for JPEG because one
of the main editor would just output all its JPEG files this way?
See: dfc63d42ee/libjpeg.txt (L1425-L1438)
… plug-in code.
In particular, we should not hardcode this in core code anymore. The
behavior is otherwise exactly the same, except that we made the core
code generic as it should be.
The CLI options now know which procedures are batch procedures or not.
First it means that it won't just randomly try any procedure name one
may pass and will properly output an error if you pass a non-existing
interpreter procedure.
Secondly, there is no default interpreter anymore (unless only one
interpreter exists). If you don't set an interpreter procedure with
--batch-interpreter or if you pass a wrong one, it will output the list
of available batch procedure, thus helping you understanding how to use
the --batch option.
Call gimp_exit() rather than emitting the signal ourselves. This way in
particular, the still-opened images are properly freed and we avoid
GeglBuffer leaks from images we might have created in a batch script, or
the images loaded in command lines.
Alan Mortensen