PDF exporting had no progression. In particular when exporting a PDF
with more a hundred pages today, it took maybe 20 secs without any
progression status, which is annoying.
Limitations:
1. When exporting as multi-images, we reset to 0 at each image. I am
actually not sure if this is the expected behavior.
2. I am updating the progression per top layer, not doing finer grained
progression steps. An extreme case would be a single top layer group
with many children layers inside. Yet I wanted to avoid too much
progression updates for the normal cases.
This commit also makes snap to grid and snap to vectors work off-canvas.
Since we now have off-canvas viewing, it just makes sense that snapping
would work there too.
Note that I disable snap to grid when "Show All" is OFF. I am actually
unsure this is right (as "Show All" is a view action, and we usually
don't change behavior based on view actions; for instance snap to guides
are not disabled if guides are hidden). Yet I noticed we do this in
various other features when off-canvas. We kind of use this view flag as
a switch for features working off-canvas (for instance, color picking
works off-canvas only when "Show All" is ON). So let's keep the same
logics for now at least.
Snap to guide or snap to vectors will always work though, because guides
and vectors are always visible off-canvas (even when "Show All" is OFF).
They always have been (visible, not snappable off-canvas; now they are
both).
Our error/message handling code was checking if the status bar label was
big enough to hold the message by checking the GtkLabel allocation. This
means that error message ended up on status bar only if a status text
bigger than the error message was previously displayed.
Even setting gtk_widget_set_hexpand() or the "expand" container child
property on the label, I could not find a way for GTK to actually give
it as much space as possible on the status bar.
Instead, I am computing the full container box size, starting from the
label x coordinate (assuming the label is the last shown widget on the
status bar, as usually the progress bar and the cancel buttons are not
shown in the same time as the message label). This gives me a much more
appropriate result of the maximum size which this label can hold without
ellipsizing.
… but only when a menu label was set with
gimp_procedure_set_menu_label(). In such case, this menu label is used
as dialog title (with mnemonic underscore removed).
Adds option for selecting predefined page sizes using the same
template selector as on "New Image" dialog.
Syncs up size and offset unit selectors to have the same value
when changing template and when resetting whole dialog.
See the discussion in #5339. Basically this is now technically a tool
(i.e. a child class of GimpTool) and tools can be activated anytime,
even when no images are opened, i.e. when they are useless (for instance
paint tools). Filters on the other hand were historically only
activatable with opened images. With time, tools and filters difference
got slimmer (until there are technically none nowadays where GEGL ops,
levels or curves are implemented as GimpTool too) if not only a
conceptual difference.
Since here GEGL Operation is really more on the "filter" side, let's
just move it to the "Filters > Generic" submenu, just next to "GEGL
Graph", also removing the mention of it being a "tool" from the help
message.
Then I will merge !402 for it to be (in)active depending on images, as
other filters do.
Since we now hide the file dialog when exporting, progression ends up
invisible, which is especially a problem with big files. Therefore use
the image display as a GimpProgress to show progression.
… gimp_parasite_data_size().
gimp_parasite_data() was non introspection friendly because calling code
needs to know the size of returned data a way or another (the concept of
data pointer with random contents, no known size and no way to know the
end of the buffer is not usable in many languages other than C).
Now that all usage have been replaced by gimp_parasite_get_data(), we
can just remove the functions from the v3 API.
When running several times an export plug-in while one is still running,
the export file dialog may get destroyed and the second running plug-in
would try to call functions on a destroyed dialog, hence crashing core
GIMP.
Similarly to the previous commit, it is not only about using the new
API. I also make sure we do not assume that parasite data is
nul-terminated. In many places, we were just assuming so because these
were supposed to be parasite our code set. Yet these are data input
contained in files which can be wrong for any reason (corrupted file,
bugs, other scripts/plug-ins editing these parasites…). So instead of
assuming string parasites are always correctly formatted, I make sure
they are nul-terminated by passing them through g_strndup() when
necessary.
Allow @num_bytes to be nullable, but add text in the documentation that
this is only useful when you want to check if there is contents.
Also make @num_bytes into a guint32, and finally set it to 0 when there
is no parasite.
Now when a gAMA chunk is set on an imported PNG (and if there is no
profile attached), an equivalent profile is created out of the gAMA
chunk. So the displayed image looks like it is supposed to.
On export, the generated profile should simply be saved together in the
PNG file. If not, the sRGB chunk is set anyway (and also an equivalent
gAMA/cHRM as recommended in the specs).
So basically we now have a proper support of the gAMA chunk, from import
to export, and display within GIMP takes this metadata into account
appropriately (in the shape of a generated equivalent profile).
Therefore it looks to me keeping the option is redundant. It is even
confusing (because it's actually hard to understand exactly what this
data is about, even our documentation about this metadata seems to be
wrong) hence possibly dangerous if someone thinks it is important,
checks the box, which would override other data or simply create
irrelevant or contradictory metadata.
So let's just remove this option. Development releases are the right
places anyway for people to notice this change and come to us if we
missed some usage regarding this option.
See also #5363.
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.
