It isn't being used by any plug-in or any code in GIMP at all even.
Let's get rid of it while we can still break API, so we can cut down on
all the complexity of the gimp-param stuff a bit.
Allow guides with off-canvas position since we can now view and work
outside the canvas.
The guide deletion interaction does not change too much, except you
don't delete a guide because it's dropped off-canvas but off the display
viewport area instead.
The XCF format is technically unchanged as PROP_GUIDES was already
expecting an int32 coordinate (with max value at GIMP_MAX_IMAGE_SIZE,
way below uint32 max anyway). Yet our code and XCF docs was explicitly
asking to ignore negative coordinate guides, which makes a change in
behavior for the XCF parser, hence a new version XCF 15. Loading will
still ignore negative position guides (even also bigger than image
dimension guides now) for XCF 14 and below, but will now accept any
position for XCF 15 and above.
Subdivise progression steps inside layer groups.
It is not perfect yet as it would not handle perfectly weird edge cases
where you have for instance a lot of layers in a top layer group with
only many other top layers. But it would still handle it better than
before. Ideally we should simply count all non-group "leaf" layers in
the layer tree and use this as the number of steps. In other words, we
should do a first pass through the whole layer tree.
- Do not only check the step width, but also the time interval between 2
progress calls. No need to run a PDB call, then update the GUI every
millisecond or so. This would just unecessarily slow down the plug-in
for updates which the user won't ever see. From my tests, 20 updates
per second is plenty enough to have the progression look fluid. No
need for much more.
- Do not warn anymore on stderr when we drop progress updates. Even if
just on the unstable builds, such warning is wrong. First because it
depends on files and machines. Typically a lot of processing could set
their progress updates relatively to layers. Yet we currently consider
that 1/256 steps are too small. So what if you have more than 256
layers? This would make the same code print a warning on big files,
and none on small files.
The second reason is that we should not encourage plug-in developers
to have limited progression updates, but the opposite (progression
info makes for good feedback), neither should we expect them to
compute the step size or the time between updates. It's a much saner
approach to have them only take care about computing relevant update
steps while our API focuses on filtering these in order to avoid
overloading the GUI.
It makes for good progression feedback, sharp GUI while not taking all
CPU time on it, all this while making it easy on plug-in developers.
The Lua API is undergoing changes in darktable master. I've fixed the lua-scripts repository as I've made
changes, but I forgot about the collateral damage.
Attached is a fixed version of file-darktable-export-on-exit.lua which should be good for darktable 3.6 and
beyond.
Fixes#6421
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!).
