Let's go with the logics "bottom layer is first", which is also the
logics in animated formats. Hence changing the layer order on loading
multi-page PDF.
gimp_config_type_register() currently overrides GimpConfig::equal()
to only compare the properties of the most-derived type. However,
this prevents the properties of GimpOperationSettings from being
considered during comparison of operation-config objects. Instead,
don't override GimpConfig::equal(), and rely on
GIMP_CONFIG_PARAM_DONT_COMPARE to exclude specific base-class
properties from comparison.
As per commit ed7ea51fb7, reintroduce
the "Fade" functionality for filters, by incorporating it directly
into GimpFilterTool.
Add "mode" and "opacity" options to GimpOperationSettings, and add
a corresponding "Fade" expander to the GimpFilterTool dialog
allowing to control them.
Reintroduce the FADE layer-mode context, and use it to mark the
layer modes avaialable for fading.
Add a new gimp_drawable_apply_operation_with_config() function,
which takes an operation node together with a config object, and
applies the operation using the config options, including both the
operation-specific options, and the common GimpOperationSettings
options.
Use the function in gimp_gegl_procedure_execute(), so that
reapplying a filter takes the common operation settings used
originally into account.
Remove the common operation settings from GimpFilterOptions, and
instead, in GimpFilterTool, store these settings in the operation's
config object, which is now a GimpOperationSettings subclass, as
per last commit.
Add a new GimpOperationSettings class, to be used as a base class
for all operation-config types. The class provides options common
to all operations (namely, the clipping mode, input region, and
color options), which were previously stored in GimpFilterOptions,
and were therefore bound to the filter tool, instead of being
stored as part of the operation settings; as a result, these
options would have no effect when reapplying a filter, or when
restoring a preset.
The GimpOperationSettings options do not affect the operation
node, but rather the associated GimpDrawableFilter object. The
class provides a gimp_operation_settings_sync_drawable_filter()
function, which applies the options to the filter.
Modify all custom and auto-generated operation-config types to
derive from GimpOperationSettings, and modify the GimpConfig
functions of the former to account for the GimpOperationSettings
properties, using a set of protected functions provided by the
class.
... which determines if a node's operation-class has a specific
key, and can be used instead of gimp_gegl_node_get_key() when only
existence is important, to avoid compiler warnings.
Update the rest of the code to use the new function.
In GTK+3 GIMP, without a "width-chars" even short layer names (a few
letters) were always ellipsized to nothingness with the "ellipsize"
property.
So add a reasonable prefered width char (which will be at most 10
characters, less if the layer name is smaller).
Also drop "xpad" property as this is now deprecated.
I don't reproduce these build warnings in my build but frogonia reported
them:
> warning: 'strcpy' accessing 1 byte at offsets 0 and [0, 2147483645] may overlap 1 byte at offset 0 [-Wrestrict]
And indeed the man of strcpy() clearly states that "The strings may not
overlap" (which is clearly not guaranted in current code as we don't
know the size of what's after the substring).
strncpy() might have done the trick as it doesn't say anything about
possible overlap or not, but let's just use memmove() instead where it
is clearly written that memory areas may overlap (note that bcopy() as
proposed by ankh would have also done the trick, but it is marked as
deprecated).
… defaults to FALSE for PNG, TIFF.
The logics is that in most case, when alpha is 0, you don't expect color
to be retrieved and some people were bothered by this when erasing data
with eraser tool or selection deletion.
For the WIP image as well as for XCF format, we definitely want to keep
color data as there are workflows where you would want to erase/unerase
pixels subtly (selection also are not binary and should not be expected
to erase color data on layers with alpha channel). So we want to keep
the non-destructive behavior there.
Yet for export formats, going for "deleting what looks deleted" is a
valid approach, especially as it has been argued that experienced users
would know how to read and change the format options (and these
experienced users are likely the ones who may have valid reasons to want
pixels with full transparency to keep color values).
PNG and TIFF were the only 2 formats where I see such options, so
changing the default for these 2 plug-ins.
… oscp-router0[12].gnome.org.
The file was opened asynchronously through g_file_read_async() but the
actually reading from a GFileInputStream was actually done in the
callback, in the main thread. So it may be possible that file is
accessible but connection is very slow or non-reliable and actual
reading would block the main process. I am assuming this is what may
have happened for this reporter.
Instead let's use g_file_load_contents_async() which does the file
opening, reading and closing all in the asynchronous task, hence would
not slow down anything even if the remote resource is unavailable or
connection is very slow.
Apparently, the "drag-begin" signal of dockbook tabs can be raised
multiple times when a drag begins (this seems to happen randomly,
and rarely -- possibly a GTK bug). In
gimp_paned_box_drag_callback(), which gets called in response, make
sure not to leak the corresponding idle source in this case, which
can lead to a segfault if the widget is destroyed before the idle
is run.
In GimpFilterTool, use gimp_drawable_filter_set_preview(), added in
the previous commit, to toggle the filter's preview, instead of
removing and re-adding the filter. This avoids destroying cached
results when disabling the preview, allowing to quickly toggle the
preview on and off to compare the result.
... which allows temporarily turning the applicator into a NOP,
without destroying cached data.
This commit also improves gimp_applicator_set_{src,dest}_buffer().
* Don't generate our own marshallers if they are available in GLib
already
* Don't set the c_marshaller parameter in `g_signal_new()` if it's a
default marshaller provided by GLib. See commit message of commit
39e4aa3c57 on why this is the case.
Revert "app: also localize LC_TIME to GUI language."
This reverts commit a4e65ac836.
LC_TIME format apparently does not accept the broader format with just
the lang part, for instance "fr". The region is necessary, like "fr_FR".
In our supported languages, we were mostly using lang only except for a
few langs where we support regional variants.
This makes sense as time format may be quite different depending on
regions (dates are quite different in GB vs US, though that was actually
one of the cases where we were using accurate locale format).
And the main issue is that it was not only breaking time localization.
Normal string localization (LANGUAGE) got somehow broken as well by
broken LC_TIME.
Anyway for now let's just stick to whatever OS-set time format (even
though it may differ from GIMP Preferences-set language defaults).
After discussing with Schumaml and Houz on IRC, let's just drop the
generic comment which may be confusing and is probably unecessary,
especially now that I write the revision number (present and new ones).
So let's just assume people understand that they should update, even
when GIMP version stays the same (this was the case I was the most wary
about, that people think the notification is an error as since they have
the last version, they don't have to update GIMP).
I hesitated to at least leave just the simple "It is recommended to
update." sentence but after much hesitation, let's go with no generic
comment at all. The download button by itself should suffice.
Of course, when a specific revision comment is set in
gimp_versions.json, it is still displayed.
- Instead of the download link being just a link button (similar to
browser "blue text" links), make it a proper button encompassing the
update icon and the download text "Download GIMP X.Y.Z".
- Make also the revision number part of the download information.
- Frame title is now "Update available!" instead of "New version
available!" (because it's not necessarily a new version, it can also
be just a package revision. "Update" is more generic).
- When no update is available, the "Check for updates" button is big and
has a label, and also now an icon. When an update is available, hence
we display now a button for the download link, the "Check for updates"
button becomes small with icon only in order not to take visual
priority over the download itself (yet allowing to re-check for even
newer information).
As noted on IRC, after the first update check on a given day, it looks
like the check button does nothing. Therefore also display the check
time to clearly show the button click was taken into account (simply
there are no updates, hence only displayed check time is updated).
Do it even on stable builds as it can help diagnose bugs on releases.
Note that the issue we had just know with casing on the build-id would
not have been seen by such stderr output anyway. Just in case for future
issues.
(cherry picked from commit dd4cec577d)
Jehan