Basically the same design as before (but a bit prettier, by using a
2 columns flowbox rather than a grid), yet 80 lines smaller according to
git stats. Also still the exact same code logics as before. No feature
loss (and actually a feature gain as there was the "Save comment"
checkbox but no text field to edit the comment as we get in other
plug-ins).
Basically better and prettier dialog in just a few lines. Moreover it's
still work-in-progress. We can even do better, but this is things to
come.
Recently updated my distrib, so it's a good time to see what is wrong in
our instructions. In particular, we must build GEGL with Cairo,
otherwise gegl:npd is not built (and it's a mandatory operation for
GIMP).
… fails.
My previous commit was just assuming there is one page when the libtiff
function fails. But thinking a bit more on this, there are 2 edge cases
even here:
- If the image is actually really corrupted to the point there are no
TIFF directories to read.
- If there are actually more available directories. It would be much
better if GIMP were able to salvage them from a broken file.
To handle these cases, I actually count manually the number of
directories by looping with TIFFSetDirectory() (which still works fine
on our minimal image). I use 65535 as a max value because in libtiff's
TIFFNumberOfDirectories() implementation, it says this is the max value
(even though I couldn't confirm this in the spec; there is a "Number of
Directory Entries" on 2 bytes, but this is about various fields for each
directories, not a number of directories; still anyway this is already a
huge number and since libtiff won't likely be able to handle directories
over this limit, not need to go over either).
I am also adding a test in the end so that we can output an appropriate
message if we actually failed to read any data from the TIFF (whether or
not TIFFNumberOfDirectories() succeeded, when we actually tried to read
the contents, we couldn't).
On a provided minimal 1×1px TIFF file, TIFFNumberOfDirectories() seems
to choke on some missing field and returns 0. I am not sure if the file
is actually valid or not, but let's make some kind of exception
(outputting a warning of our own when we do) by assuming there is at
least 1 page/image in the file when TIFFNumberOfDirectories() returns 0.
Other than this minimal file (which probably has no other interest than
being a test case), it could actually help salvage corrupted TIFF file
by attempting to read more data.
… in Image properties window.
Basically using non-translatable "%s (%d %s)" and filling it with
"Indexed color" base type name and translatable _("colors") is very bad
practice (localization-wise):
- First it assumes everyone uses round brackets.
- It also assumes the order of words (number before word it determines
but even the image type before detail brackets).
- And finally it doesn't handle plurals. Of course, we could say that
the 1 color case is a very edge impractical case, but plural is not
only about 1 vs other numbers. Some languages have more cases, and
using ngettext allows translators to handle these.
First of all, "CJK Unified Ideographs" block should not be the highest
priority to determine showing an ideograph. Indeed most fonts for a
Korean and Japanese audience would also contain at least the main
ideographs. So instead, look first for Korean alphabet (Hangul) and
Japanese syllabaries to determine if it's a Korean or Japanese-targetted
font. Only then Chinese.
Also check Korean before Japanese because most of the Korean fonts I saw
actually also include Japanese syllabaries (but not the other way
around).
This way, it will be much easier for CJK graphists to skim through the
font list and detect fonts made for the needed language in a glance.
Also modifying the Korean display text. KIYEOK and SSANGKIYEOK were
obviously chosen because they were the first in the block. But they are
very bad choice. We hesitated with 가 at first, as it is considered the
first in the syllabary form (가나다라 is kind of similar to our ABCD).
But it wouldn't show a form with a second consonant (below) which is a
good stylistic indication. So we hesitated between 한 (han) and 글
(geul, which also means text so it's a nice sample), and finally went
with 한 because of the circle shape in ㅎ (hieut) but also its small
"hat" which has many stylistic variants. So it's quite a good hint of
stylistic choices made by a font designer from just the sample box.
Moreover I switched the block check from "Hangul Jamo" to "Hangul
Syllables" block. "Hangul Jamo" are positional forms of the letters to
dynamically compose syllables (in particular legacy syllables not in use
anymore). Though a feature-full Korean font set would design these, it
is less important than "Hangul Syllables" (pre-composed syllables
design) or "Hangul Compatibility Jamo" (basically the same letters as
"Hangul Jamo" but for standalone usage). Also I actually saw some fonts
made for Korean without "Hangul Syllables" support.
Finally I also added a test for Japanese. I check the Hiragana block
which is most likely the most basic which has to be in any
Japanese-targetted font and use 'あ' (a) as sample text, which is the
first Hiragana syllable and here definitely a good sample text in my
opinion.
I believe that this can still be improved though. Checking only a single
block to determine the probable target language is not necessarily
enough. For instance very complete fonts for Chinese may also design
Korean and Japanese characters, but will also have most CJK blocks and
more ideographs (whereas Japanese/Korean will likely have less). Yet
let's say this is good for now, at least better than before!
pango_fc_font_lock_face() is deprecated since Pango 1.44.
This may hopefully also fix#5922 as I completely changed the code where
the CRITICAL happened. Yet I left g_return_val_if_fail() to check if the
Harfbuzz font and FreeType face variables are not NULL (because looking
at the code, it looks like these functions returning NULL actually means
there is a bug in the code).
Nevertheless if it turned out that there are non-bug cases where these
could return NULL (for instance a broken font file?), then probably we
should not use g_return_val_if_fail(), but instead address the data
issue in a nicer way.
Bumping harfbuzz dependency to 1.0.5 for hb_ft_font_set_funcs(). Without
configuring the Harfbuzz font with it, hb_ft_font_get_face() always
returns NULL.
Note that it looks like hb_ft_font_lock_face() would actually be better,
but this requires harfbuzz 2.6.5 from last April which is quite recent.
So let's just use the get_face() variant for now.
Existing implementation was repeating the hours and minutes. This was
obviously not what the format asked. The last hour and minutes are the
ones from the timezone offset. Also rather than playing with snprintf()
and various calls to get each component, let's use g_date_time_format()
which is done exactly for such use case.
It is to be noted that there seems to be a bug in Exiv2 such that the
date and time set through Exiv2 return an error when read back, still
with Exiv2. Read and write use different format. I have reported this
issue, together with a patch (hopefully a good one).
https://dev.exiv2.org/issues/1380
So once this patch (or another) gets merged upstream, the following
warnings (e.g. when reopening a PNG created by GIMP) should disappear:
> ** (file-png:176245): WARNING **: 02:43:25.204: Unsupported date format
> ** (file-png:176245): WARNING **: 02:43:25.204: Unsupported time format
`man snprintf` clearly says (in NOTES) that when source and target
overlap, the result in undefined.
g_snprintf() conforms to the same standard hence would not get the
expected result. In my case, the result was just tzstr (e.g. "+01:00").
gimp_procedure_dialog_fill_frame() allows creating a GtkFrame, in
particular with a boolean widget which can therefore control
sensitivity of the frame contents.
gimp_procedure_dialog_get_label() creates a simple text label.
- New GimpLabelIntWidget which is a label associated to any widget with
an integer "value" property.
- New gimp_procedure_dialog_get_int_combo() which creates a labeled
combo box from an integer property of the GimpProcedureConfig.
- Renamed gimp_procedure_dialog_populate*() with
gimp_procedure_dialog_fill*(). Naming is hard! I hesitated using
_pack() as well (similarly to GtkBox API).
- New gimp_procedure_dialog_fill_flowbox*() functions to create a
GtkFlowBox filled with property widgets (or other container widgets as
we can pack them one in another). This is an alternative way to build
your GUI with sane defaults, with list of property names.
The color space label may be a bit long (depends on profile title which
may just be anything and we don't control it), so I allow it to wrap.
The file path on the other hand would not work well with wrapping. It
already has ellipsis in center, but GTK always gives the max size it can
as a default. So if the file is even just slightly deep in the file
tree, we end up with extra-wide Image Properties dialog.
My trick is to give a sensible max size at dialog creation (25
characters max) but to disable this max size as soon as the window gets
realized, hence allowing the label to actually grow up to the contents
actual max size, were one to manually resize the window.
"RGB color" is not a color space, only the model. To get full color
space information, we want to display the model and associated profile
name.
Of course, the "Image Properties" dialog also has a tab displaying
details about the color profile. Still it's better if the general info
displays not too wrong label contents.
Note: when the used color profile has no name, it will show "(unnamed
profile)" which is still more informative than just the color model.
- Set the software as `initialized` later, and in particular after all
recovered images (from crash) then all command line images were
opened. The reason is that the DBus calls have necessarily been made
after GIMP was started (typically could be images double-clicked
through GUI). We don't want them to appear before the images given in
command line (or worse, some before and some after).
- Process DBus service's data queue as a FIFO. The image requested first
will be loaded first.
- When a DBus call happens while GIMP is not initialized or restored,
switch to a timeout handler. The problem with idle handlers is that
they would be attempted too often (probably even more during startup
when no user event happens). This is good for actions we want to
happen reasonably quickly (like would be normally DBus calls), but not
when we are unsure of program availability schedule (i.e. at startup).
Here not only the handler would run a lot uselessly but it would
likely even slow the startup down by doing so. So while GIMP is not
initialized, switch to half-a-second timeout handler, then only switch
back to idle handler when we are properly initialized and GIMP is
ready to answer calls in a timely manner.
… DBus calls.
In particular, Aryeom would start GIMP and directly double click some
image to be loaded in GIMP in the very short while when splash is
visible. Previous code would wait for the `restored` flag to be TRUE.
This was nearly it as we can actually start loading images as soon as
the 'restore' signal has passed. Yet the flag is set in the main
handler, but we actually also need the <Image> UI manager to exist,
which is created in gui_restore_after_callback() (so also a 'restore'
handler, yet after the main signal handler, i.e. after `restored` is set
to TRUE). Without this, gui_display_create() would fail with a CRITICAL,
hence file_open_with_proc_and_display() as well.
I could have tried to set the `restored` flag later, maybe with some
clever signal handling trick (and handle both the GUI and non-GUI cases,
i.e. I cannot set the flag inside gui_restore_after_callback() as it
would break the non-GUI cases). Instead I go for a simpler logics with a
new `initialized` flag which is only meant to be set once, once
everything has been loaded, i.e. once you can consider GIMP to be fully
running hence ready to process any common runtime command.
This is a continuation of #5888 as I realized that most layer modes were
fixed with my commit b3fc24268a (and follow-up f40dc40cbc) but at least
2 were still crashing GIMP: "Luma Lighten/Darken only" modes.
There were 2 bugs here:
* The first bug was that when gimp_operation_layer_mode_real_process()
ran, gimp_operation_layer_mode_prepare() had not been run yet.
prepare() is called before the process() of GeglOperation, but it
would seem the process() of GimpOperationLayerMode on the other end
happens before GeglOperation's prepare() is run. I am absolutely
unsure if this is expected or not and have a hard time figuring out
all the details of the C/C++ cohabitation.
As a solution, I am moving out the fish caching (the needed part
inside gimp_operation_layer_mode_real_process()) in its own function
so that I can easily call it separately before inspecting the fishes.
* The second issue was that some blend functions needed more than a
GeglOperation alone. E.g. blend_function() for luma lighten
gimp_operation_layer_mode_blend_luma_lighten_only() would call
gegl_operation_get_source_space() which requires the node to exist.
Similarly for the Luma darken only mode. So I keep both the node and
operation around, and when finalizing, I free the node (which in turn
frees the operation).
Ell > if you are reading our commits, I would really appreciate your
review (or fixes) of my code here! :)
My previous commit broke the autotools build. Apparently when using
g_object_unref(), some C++ symbol leaked into libapppaint.a archive
library, hence the main binaries (e.g. gimp-2.99) could not be linked
without adding -lstdc++ flag:
> /usr/bin/ld: paint/libapppaint.a(gimppaintcore-loops.o): undefined reference to symbol '__gxx_personality_v0@@CXXABI_1.3'
> /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: error adding symbols: DSO missing from command line
Not exactly sure why using this GLib function in particular caused this,
but let's just try another approach in order not to link the main binary
with C++ standard lib.
Instead let's manage all GeglOperation allocation in gimp-layer-modes.c
by adding a gimp_layer_modes_exit() function and some static array for
storing operation object of each layer mode.
The GimpOperationLayerMode variable member in DoLayerBlend was not
properly constructed. C++ class constructor can be called by creating
object variables, but with GObject, we have to do it with pointers.
Otherwise here we were only allocating the memory for the struct, but
not actually calling any initialization functions.
Also it would seem that the struct was not initialized at zero, as the
space_fish variable was not NULL when it should (i.e. even with same
composite and blend space), hence composite_to_blend_fish was not NULL
and since the operation was not a valid GeglOperation when entering
gimp_operation_layer_mode_real_process(), we crashed.
Not sure how it went unseen for so long!
So instead let's make the layer_mode class member into a pointer. As
such, I have to properly allocate and free it. This is also why I am
adding a copy constructor which will ref the pointer (otherwise we unref
more than we ref as the default copy constructor would just copy the
pointer).
So the minor fix on commit 3e35fe4d80 was not so minor after all, and I
should have looked more in details into its contents.
GET_PRIVATE() macro uses the `priv` pointer value hence had to be called
after gimp_chain_button_get_instance_private(). Thus the order was
important; the initialization and assignment values were actually
different. Simply let's get rid of the previous initialization of
`private` (make it declaration-only) to avoid cppcheck to (wrongfully)
complain about double variable assignment to the same value.
We are not going to duplicate the whole autotools documentation. Let's
rather just state we follow the GNU build standards, hence refer to
relevant documentation with a link.
Probably one of the simplest plug-in dialogs, with only few properties
and all in the main box. So it's quite easy to port, even with the still
limited generation API.
- Add some border width on the main dialog box.
- Remove the additional border width on the button box but add some
padding instead to separate it a bit from the specific plug-in
widgets.
- Add GimpLabelSpin as one of the possible property widgets to represent
an integer property and make it the default.
- Put labels of GimpLabeled widgets into a common GtkSizeGroup so that
labels and entry widgets are aligned, hence much faster to parse with
the eyes.
Jehan