Before you get too exceited -- no, this commit doesn't integrate
transform previews into the image graph :) We still use a
separate canvas-item overlay, just like before, but instead of
using an impromptu implementation to render the preview, we use
gegl:transform. We properly adjust the matrix passed to the op
according to the display scale, so that we still render only as
much as needed.
This is both notably faster than the current code, and, for
perspective transforms, more accurate.
Whereas we would only scale *down* big pixel images, we should both
scale up or down vector images since such format is made for display at
any size. This way, a vector splash screen is always displayed at ideal
size, whatever your display size.
Current code was using the dimension of the screen as a max size. That
is really too big. 2/3 of the screen size is an acceptable size being
both well visible and not overwhelming.
Also the current code was cropping, not rescaling, the splash image,
which is obviously not an acceptable solution because on a very small
displays, we would end up with ununderstandable piece of a bigger image.
This new code will allow to ship big size default splash image(s), and
display it in an acceptable size on both low and high density displays.
We indeed got a feedback from someone with a 4K display who was saying
the current dev splash screen was tiny on one's display.
Of course, custom splash can still be at any size; but from now on, we
will need for the *default upstream splash image(s)* to be of huge
dimension in order to show up well everywhere (at least Full HD splash,
which is half of a 4K UHD screen).
Animated splash images are still not resized though and will show up at
their default dimension. This means we cannot ship animated splash
screens as a default for the time being (they can still be installed as
custom splash).
The four remaining "classic" color tools (Brightness-Contrast, Curves,
Levels and Threshold) are in fact just special UIs for otherwise
completely normal filter ops.
Add normal filter actions for them and invoke them like all
other filters, which makes them show up in the filter history
automatically.
The only small hack needed is to special case them in
gimp_gegl_procedure_execute_async() so the right tools are created
instead of the default GimpOperationTool. Also, blacklist the
automatically generated tools actions from action search and the
shortcut editor.
I completely forgot to rename the appstream file according to the new
ID. While doing so, I also make it a .in.in file, with initial
processing by the autotools. Indeed I need @GIMP_COMMAND@ to be replaced
by AC_CONFIG_FILES().
Finally I fix a badly closed XML tag (which reminds me I should always
test a commit, even when it's a simple non-C 1-liner change!).
From AppStream docs:
«
In previous AppStream releases, the <id/> was used to associate metainfo
files with their .desktop files to merge in data from .desktop files
into the AppStream generator's final output. In modern metainfo files,
the component-ID for desktop-application components can be an arbitrary
string (matching the naming rules applying to all AppStream metadata),
while the <launchable/> tag is used to associate .desktop files with
their metainfo files.
»
... used for Flatpak.
Additional comments by Jehan after review:
«
This is not only to sync with flatpak. This format is the recommended
format in AppStream spec, even though many historical application still
use the old format.
If ever we decide to propose a dbus service, this may even become
required.
However just changing this is not enough for a proper ID change. I will
make additional change in further commits.
»
gimp_action_history_init(): when deserializing the action history,
check each action against gimp_action_history_excluded_action() so
when we decide to exclude an action, it doesn't come back as history
zombie from disk.
While we are at it, let's just add RGBE exporting. It's just as easy.
Also rename s/file-gegl-load-rgbe/file-load-rgbe/. All formats just use
the "file-FORMAT-(load|save)" naming for their procedure, even when
implemented directly through "gegl:load|save".
It seems that various software use something different after the "#?",
and even Blender code just ended up only use these 2 characters as magic
number. See also bug 792453.
... be used effectively.
We have had display pixel density detection for quite some time, but I
guess the step I set to switch to the "Huge" icon size (48px for the
toolbox icons) was too high at 300 PPI. Someone with a screen of about
280PPI reported the icons to be far too small on GIMP 2.9.8.
It seems that 240PPI is already even considered as XDPI already. Let's
just set our new "Huge" step at the 250PPI intermediate.
In any case, it seems GIMP 2.10 will have problems with even denser
displays, but the way GTK+2 handles icon sizes with a GTK_ICON_SIZE_*
enum is quite limited. That is quite a problem considering screens
getting denser in pixels nowadays. Hopefully GTK+ 3 will improve the
situation.
This makes no functional differences since this package has a pkg-config
file only since 0.4.7, our current requirement. This means that
searching for any poppler-data through pkg-config is the same as
searching for this minimum version.
But at least that makes for better output in case of error. People who
wish to build GIMP will have proper error information of the minimum
requirement for poppler-data.
Please don't forget to notify me too of an upcoming release. I need to
update the manifest (for stable releases at Flathub at least, since we
have not set the dev release process yet) and trigger a new build of our
flatpak.
Trying to manually read commits to acknowledge translators, designers,
developers, etc. is just ridiculous. Let's try to have a script doing
the work for us.
You use it like this:
- GIMP 2.9.8 stats: devel-docs/release-stats.sh GIMP_2_9_6 GIMP_2_9_8
- GIMP 2.10 stats: devel-docs/release-stats.sh GIMP_2_8_0
Various plug-ins exporting metadata should now follow preferences, which
would override any default. Of course these preferences can still be
overriden by saved settings (global parasite), previous run settings,
and finally through the GUI when interactive.
gimp_image_metadata_save_prepare() now back to suggesting metadata
flags, but this time with reasonnable base. It indeed uses the presence
of particular metadata, but also whether the preferences asks for this
metadata to be exported by default or not.
...on the list dialogs on the Input text area
gimp_container_editor_constructed(): connect the container
view's "select-item" with G_CONNECT_AFTER because the signal
is G_SIGNAL_RUN_LAST. Some quick greps didn't find anything that
would be affected, except fixing this bug. Found by Massimo.
...instead of center
The scale tool implicitly uses GimpToolTransformGrid's "pivot-x" and
"pivot-y" properties, so they need to be properly initialized and
updated to be at the grid's center.
Also add a tool options toggle "Around center".
The returned flags should not be called "suggested" flags anymore.
Having metadata available in the work image does not mean we want them
exported absolutely, which can be a security risk, especially for the
metadata which are there from the imported image.
This is a privacy concern. Whereas importing metadata is usually a good
idea, exporting it should be a conscious action. A lot of private data
can be leaked through metadata and many people don't realize it (which
also usually means they don't need it). On the other hand, the people
who realize it are the ones who would explicitly edit the metadata and
check what they want to be exported or not.
This is only a first step. Some people may want to always export the
metadata and for these people, there should be abilities to change the
default.
The attached patch avoids CRITICALs when executing Debug actions
with no images open.
1) do not run projection benchmark unless there is an image
2) memsize of pluginmanager member was incorrectly computed using
gimp_object functions for 2 GObjects
This reverts commit 36258a671a.
This commit was making the rotated canvas rendering quite horrible to
the point that I think it would make the canvas rotation feature barely
usable. See bug 759287, comments 13 to 18.
I think we will need to find other ways to accelerate rendering.
Compromise on quality is possible, but I think that in this case, this
was more than just a compromise. It was more like completely abandonning
quality. We could even see the lines "spiking" while you were rotating!
Like your drawing was alive!
When running strtok() the first time, it needs to be non-NULL so we must
check for the string. This is even more important because NULL actually
has a special meaning in strtok() to indicate further search on the same
string, in a stateful way. So searching with NULL at first call was
crashing the metadata editor plug-in in my case.
I could also imagine it could have reused strings from previous
searches, mixing metadata contents in some edge cases. Anyway that would
be bad as well!
While I was there, I also checked for non-null search string before
strstr() calls, when there was not already such a check before. This
function also requires non-NULL haystack argument.
It feels like this code doesn't do much validity checks, and it's likely
there are more similar issues. I haven't reviewed the whole code, only
this part which was crashing here.
