Similar to the --enable-g-ir-doc option I just added on autotools. Also
separate this option from gtk-doc as it is unrelated (not everything
under devel-docs is related to gtk-doc!).
When GIMP_DEBUG=Gtk we can get a warning like
State 0 for GimpChainLine doesn't match state 128 set via
gtk_style_context_set_state () when moving the mouse over
a chain like the one in the Scale Image Dialog.
Let's remove this warning by setting the correct flags by
calling gtk_widget_get_state_flags.
The openraster plug-in uses the png plug-in in non interactive mode
to load and save layers. With a lot of layers we get a lot of
flashing popups because of the progress dialogs.
When it is called in non interactive mode there should not
be a need for progress dialogs so let's disable them in
that case.
The Openraster plug-in calls file-png-load and
gimp-file-load-layer but didn't check if the result
was SUCCESS. Even though I haven't seen any
failures let's improve error checking by adding
a check for a correct result.
The current openraster specification only has a limited
number of layer modes. Let's improve things a little bit
by mapping both the current and legacy layer modes
to the same openraster composite-op where available.
For the other layer modes we could examine what the
closest composite-op is, or add a GIMP specific op
(which is what Krita seems to do). For now we set
all these to the openraster equivalent of NORMAL.
Let's use the non legacy layer modes when importing/exporting
openraster images. That way we are more likely to be able to
import the correct layer modes since openraster only has a
limited number of layer modes defined.
XMP metadata saved by GIMP 2.8.x or earlier can have duplicate tags
making the XMP data invalid. There's not much we can do without a
whole lot of processing and complicated code and even then no
guarantee we would catch everything.
Instead let's just try to improve the message to the user so they
will be more likely to understand what's going on.
Using a `GtkListBox` allows us to make more complex widgets when trying
to showcase an icon theme. For example, we can make the example icon a
bit bigger so you don't have to squeeze your eyes to distinsguish them
one from another.
Other possibilities we can do with this widget, is for example making
the folder label clickable to open the file explorer, or add a flat
button at the end with the same purpose. Since it's now just a
`GtkLabel`, we can also make the path selectable (for copy-pasting).
Using a `GtkListBox` in the "Image Window Title & Statusbar formats"
preference pane allows us to make more complex rows, such as adding a
visual example of how the format string behaves on a given image title.
This commit just converts the `GtkTreeView` into a `GtkListBox`, so
nothing has functionally changed (yet), except that rows now give
feedback when the user hovers over them.
This feature adds new 'Load in reverse order' toggle box to allow
selection of order of PDF pages before importing them as a layers or
images.
Adds new bool parameter 'reverse-order' to Non-interactive mode.
Order of parameters was also changed from (password, n-pages, pages)
to (password, reverse-order, n-pages, pages)
Although I haven't been able to reproduce it, it is apparently
possible to get a Stack Overflow when loading xcf files with
presumably very large dimensions on Windows. From what
I'm reading Windows normally has a smaller stack size than
Linux, probably why it hasn't surfaced there.
Instead of allocating on the stack let's do a g_malloc0
combined with g_free.
Based on the proposed process proposed by Akkana Peck. Thanks Akk!
For now, it's only in the meson build, which is fairly terrible to use
as soon as we do custom build rules. Here are the list of issues:
- meson does not allow building in subdir (issue 2320 on meson tracker).
Sure I could make several subdirs with meson in them. But here the
future goal would be to be able to generate docs for other
introspected languages, and maybe also other output formats (epub or
whatnot). For this, since these are basically the same commands which
are used, the best practice would be to have loops generating one
target per language/format combination, reusing code rather than ugly
copy-pasting in subdirectories' meson files).
- custom_target() requires the output parameter to be the complete list
of generated files. But we have more than a thousand of them. It's not
practical. Maybe we could try to find a way to generate the list from
the contents of the .def files which are already exhaustive and exact.
- Install also requires the output list to be complete.
- I temporarily have these docs not generated by default (because the
gtk-doc option is already crazy slow as it is, making meson near
unusable for development if it's enabled). If you want to generate the
docs, the commands are as following (yeah I don't understand what the
target names are for since meson does not actually create targets with
these names, so we have to use fake output names instead):
> ninja devel-docs/g-ir-docs/Gimp-python-html
> ninja devel-docs/g-ir-docs/GimpUi-python-html
The `precision` parameter in particular had no min/max, which meant we
could provide a forbidden parameter (e.g. a negative precision) which
would cause a core CRITICAL. We must forbid illegal values from PDB side
(hence outputting a normal plug-in error message, not a core bug).
Also improving a bit the description of this parameter as I was
wondering what precision was needed exactly to get a stroke length. This
is the precision for determining whether a portion of the stroke is
"straight enough" or if we want to break it into smaller pieces until we
get a straight portion.
All it will mean is that we are looking for perfectly straight lines
when deciding if a bezier curve can be considered straight. It's a fair
condition and represents perfectly what a precision of 0.0 would mean.
… apply to GIMP GUI not text layer rendering in image.
Reviewer note: this is the theoretical fix, but it won't work right now
because Cairo explicitly bypasses grayscale antialiasing when system set
subpixel one. Still let's push this first patch, but the issue will be
actually fixed when Cairo will merge my MR too:
https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/114
In GIMP 3, plug-ins are mandatorily under a subdirectory. Though on GIMP
2.10.x, both cases are still possible. So only the previous commit
should be backported to gimp-2-10 branch.
See discussion in !392.
Thanks also to Christopher Nielsen for helping.
This commit fixes the issue when requested page width/height was
not honored because DPI resolution value was constrained to whole
integer numbers only.
The tool now takes care of the portion of the layer effectively displayed
on the screen. This allows faster expansion/shrink of the selection since
an area smaller than the whole layer is used.
It will also limit the impact of the incoming multilevels processing, which
tends to decrease the segmentation accuracy on thin structures, since users
often zoom-in to work on such thin details.
PNG has support for profiles, which is the state-of-the-art way to
handle color management nowadays. But it also had some very basic color
management based on a gAMA chunk (for the gamma) and a cHRM chunk
(primary chromaticities).
We don't have a core concept with just these and don't want to walk
backward anyway, but we can easily make basic RGB profiles from these.
This is what this commit is about. It generates profiles at import which
were not actually inside the image, but only represented by these 2 PNG
chunks. What gives it away is that GIMP will propose to convert/keep the
profile at start (unless configured otherwise, as any profile), and the
profile name will specify it is a profile generated from PNG chunks'
values. One can even discard the profile later (if you didn't convert),
so it gives a solution if somehow these metadata were not proper.
darktable GUI is "mangled" when opened from GIMP for a reporter. There
was already some debug info outputted (when running with DARKTABLE_DEBUG
environment variable). Adding the environment list (and some separation
titles to make it easier to distinguish what is what). Hopefully it will
help debugging.
See #6195 and https://github.com/darktable-org/darktable/issues/7402
We were not handling all possible record sizes for mask info and
in case it was an unknown size we set everything to 0 instead
of reading the parts we do recognize.
Let's make it more flexible by reading the parts we do know
about and skip the remaining data if any.
Also added a few more g_debug statements to make it
easier to check some values when needed.
Not sure why we didn't see the crash earlier and it suddenly shows up
now. Anyway we must delete the exported image **after** calling
gimp_procedure_config_end_export() on it, obviously.
Commit 01e1587ec1 had directly edited the Makefile.am, which was wrong.
This file is generated by plugin-defs.pl. Add the proper dependencies
for file-heif and regenerate the Makefile.am.
When a profile is set, we should not set the sRGB chunk, because it
would be a contradiction. But when we don't set the profile, then our
code explicitly saves as sRGB. So let's add the sRGB chunk.
Also when we do so, let's also set the relevant gAMA and cHRM chunks
corresponding to sRGB as recommended by the PNG spec:
> An application that writes the sRGB chunk should also write a gAMA
> chunk (and perhaps a cHRM chunk) for compatibility with applications
> that do not use the sRGB chunk. In this situation, only the following
> values may be used: […]
This is why I use png_set_sRGB_gAMA_and_cHRM() and not just
png_set_sRGB().
See also discussions in #5363.
