The gimp-2-10 patch contributed as !514 was slightly different from the
master one as !515, especially since the last one got the reviews. This
syncs the 2 codebases (making it easier to backport future patches on
the same piece of code) and do a few fixes.
- Syncing alignments.
- Fix a comment.
- Use g_build_filename() for properly creating paths rather than string
concatenations.
Freedesktop (XDG) portals are a collection of D-Bus APIs that work
across desktop environments, display servers and work within
containerized applications, like Flatpak. The internal implementation
can then choose to implement these in such a way that takes into account
security considerations, as well as making sure the user consents to
certain actions.
One such portal is the `Screenshot` portal, which contains a
`Screenshot()` method as well as `PickColor()`. We already use the
former for taking a screenshot, and this commit makes sure our color
picker also makes use of the latter.
By doing this, color picking is now possible on the major Wayland
compositors.
(Honestly, we should remove DE-specific backends like that of KWin, to
have less variation on the possible results of a color picking
operation).
Fixes https://gitlab.gnome.org/GNOME/gimp/-/issues/1074
(cherry picked from commit e82f6d5b0f)
Looking further at this widget, many things are not right. Here are the
changes:
- Use binary prefixes (i.e. kibibyte, mebibyte and gibibyte) instead of
decimal ones. We are making binary shifts so we were actually showing
the wrong units.
- Round the value to the closest integer when showing it, not towards 0.
Otherwise I had cases where it was showing 7GiB for an actual value of
7.69GiB (default as computed by GIMP from my actual physical memory).
Note that I am actually unsure even rounding makes sense. Shouldn't we
rather show double values with a few digits after the decimal points?
For such values, I think it would make sense.
- Do not edit the internally saved accurate value when the entry is
edited to the same less accurate value as our saved value would be
shown too. In particular when changing the display unit to a bigger
one, we don't want to lose accuracy. This is especially true for low
values. Say you don't have a lot of memory and you set the Tile cache
size to 1.5GiB (1536MiB), you certainly don't want it to become either
1 or 2GiB when switching display unit to GiB. Now even if the number
will still display with less accuracy, the internal value will stay
accurate.
(cherry picked from commit d886bb1b90)
This bug doesn't happen when setting value through the GUI as in such
case, the unit never changed. It happened when setting a value which
could not be properly displayed by current unit (typically smaller than
1 in this unit, or with remainder).
In such a case, we should not manually set private->shift before
gimp_int_combo_box_set_active(), or the callback was failing to
reconfigure the GtkAdjustement, in particular min and max values.
As a consequence, hitting a Preferences reset, with a GimpMemSizeEntry
in Gigabytes, it got reset to Kilobytes with the max values capped at
4096. So I realized a Reset ended me with a Tile cache size of 4096 KB
in particular, which is of course ridiculously small and would be a
problem if one doesn't notice the issue immediately.
(cherry picked from commit 0be4e5c1dc)
In GimpSpinButton, don't propagate Enter key-press events if
updating the spin-button's value in response changes the entered
text. This prevents confirming dialogs when hitting Enter after
entering a math expression in size entries, updating their value
instead.
Likewise, don't propagate Escape key-press events if a new value
was entered, and restore the original value instead.
(cherry picked from commit e531023031)
Use the right GtkAdjustment in gimp_scale_entry_log_to_linear().
See merge request !49.
Thanks to MihailZenkov for spotting this!
(cherry picked from commit 5dc1572b01)
In GimpSpinButton, adjust the scroll step in response to modifiers:
normal scrolling uses the step increment, Ctrl uses the page
increment, and Shift scales the step increment down by the ratio
between the page and step increments (up to the minimal precision
of the spin button).
This applies to all spin buttons used in GIMP, including spin
scales.
(cherry picked from commit ac8bf47fa6)
Add a new 3D Transform tool, based on GimpToolTransform3DGrid,
added in the previous commit. The tool UI provides a notbook with
three tabs, corresponding to the three GimpToolTransform3DGrid
modes:
Camera - allows setting the primary vanishing point, as well as
the camera's focal length, expressed either directly, or as the
camera's angle of view, relative to the whole image or the
transformed item. By default, the vanishing point is aligned
with the item's center, and the angle of view is fixed relative
to the item; this essentially means that each item is transformed
using a local perspective, independent of its position and size
relative to the image. A global perspective can be achieved by
using a common vanishing point and focal length (or an image-
relative angle of view).
Move - allows moving the item using X, Y, and Z offsets.
Rotate - allows rotating the item using X, Y, and Z Euler angles.
The order of rotation of the different axes can be controlled by
a set of numbered buttons next to the sliders, and the rotation's
pivot can be controlled using a pivot selector.
GimpPivotSelector is a 3x3 grid of toggle buttons, used for
selecting a natural pivot position (e.g., for a transform) relative
to an item: its center, its corners, and the midpoints of its
edges.
In GimpSizeEntry, the value corresponding to 0%, as per
gimp_size_entry_set_size(), may be non-zero. This works correctly
when using the size entry in percentage mode, but not when using
precentage as part of arithmetic.
Fix this by adding an 'offset' parameter to eevl's unit-resolution
callback, which can be specifies a constant value to add as part
of unit conversion, after scaling the converted value by the
conversion factor. In GimpSizeEntry, use this parameter to offset
percentages by their lower bound.
In gimp_page_selector_add_frame(), if "gimp-frame" icon cannot be loaded
(which should not happen, but reality can always strike back!), we want
to abort from gimp_page_selector_add_frame() immediately.
Also as a consequence, its return value might be NULL, hence should be
freed with g_clear_object() instead.
This happened here because of broken meson rules (which didn't install
this icon) and ended up in forever looping errors when loading a
multi-page PDF (pages are shown in frames in a dialog):
> (file-pdf-load:12348): GdkPixbuf-CRITICAL **: 11:59:28.513: gdk_pixbuf_copy_area: assertion 'src_pixbuf != NULL' failed
(cherry picked from commit 9dcdf37ab3)
Add a new Offset filter tool, as a front-end to gimp:offset. The
tool replaces, and provides the same interface as, the drawable-
offset dialog, while also providing live preview and on-canvas
interaction.
Note that we don't simply use a custom propgui constructor for
gimp:offset, since we need a little more control.
(cherry picked from commit 3a4a00c71e)
When the "wrap" property of a GimpSpinButton is TRUE, wrap-around
out-of-range values entered through the spin-button's text entry,
instead of clamping them. Since we're using GimpSpinButton
everywhere since last commit, this applies to all our angle-entry
spin buttons (including spin scales).
(cherry picked from commit 8b3c7ae193)
In GimpChainButton, emit the "toggled" signal whenever the chain
button's "active" property changes, either due to user interaction,
or programatically. Previously, it would only get emitted when the
button was actually clicked.
In particular, this fixes an issue where the aspect ratio of a
coordinates size-entry won't get updated when its chain button got
toggled programatically, as can happen with the scale tool.
(cherry picked from commit c0c055b4e9)
... and corresponding gimp_chain_button_{get,size}_icon_size()
functions, which control the chain-button's icon size.
(cherry picked from commit 8d6c7e42bf)
We were doing it all the wrong way, fixing one combo box object at a
time. So this commit basically reverses commits 68a33ab5bd, 6dfca83c2a
and a9a979b2d0 and instead runs the same code in the class code. This
way, all objects based on these base classes will have the fix from
scratch.
These improved various other drop-down lists (I found some of them, and
probably not all) as I fixed all GIMP custom widgets based on
GtkComboBox.
Note that it has to be run after filling the list apparently (I had the
problem especially with GimpIntComboBox if running in the _init() code,
then the list widget showed wrong).
(cherry picked from commit 1d984542e9)
...palette views despite selected color being in the currently
selected pallette
As suggested by Massimo, changing the color comparison EPSILON in
gimppalette.c from 1e-10 to 1e-6 fixes this, and is really small
enough.
Also, generally clean up color comparison epsilons:
- use a #define, not hardcoded values for all uses of
gimp_rgb[a]_distance()
- call the #defines RGB_EPSILON and RGBA_EPSILON
- make them all 1e-6 or larger
(cherry picked from commit abd7cbfc8d)
This was my initial choice, but the more I think about it, the less I am
sure this was the right choice. There was some common code (as I was
making a common composite bucket fill once the line art was generated),
but there is also a lot of different code and the functions were filled
of exception when we were doing a line art fill. Also though there is a
bit of color works (the way we decide whether a pixel is part of a
stroke or not, though currently this is basic grayscale threshold), this
is really not the same as other criterions. In particular this was made
obvious on the Select by Color tool where the line art criterion was
completely meaningless and would have had to be opted-out!
This commit split a bit the code. Instead of finding the line art in the
criterion list, I add a third choice to the "Fill whole selection"/"Fill
similar colors" radio. In turn I create a new GimpBucketFillArea type
with the 3 choices, and remove line art value from GimpSelectCriterion.
I am not fully happy yet of this code, as it creates a bit of duplicate
code, and I would appreciate to move some code away from gimpdrawable-*
and gimppickable-* files. This may happen later. I break the work in
pieces to not get too messy.
Also this removes access to the smart colorization from the API, but
that's probably ok as I prefer to not freeze options too early in the
process since API needs to be stable. Probably we should get a concept
of experimental API.
(cherry picked from commit cd924f453a)
This commit implements part of the research paper "A Fast and Efficient
Semi-guided Algorithm for Flat Coloring Line-arts" from the GREYC (the
people from G'Mic). It is meant to select regions from drawn sketchs in
a "smart" way, in particular it tries to close non-perfectly closed
regions, which is a common headache for digital painters and colorists.
The implementation is not finished as it needs some watersheding as well
so that the selected area does not leave "holes" near stroke borders.
The research paper proposes a new watersheding algorithm, but I may not
have to implement it, as it is more focused on automatic colorization
with prepared spots (instead of bucket fill-type interaction).
This will be used in particular with the fuzzy select and bucket fill
tools.
Note that this first version is a bit slow once we get to big images,
but I hope to be able to optimize this.
Also no options from the algorithm are made available in the GUI yet.
(cherry picked from commit 8ed12b1b98)
... as I would like it to.
Use GimpSpinButton, added in the previous commit, in GimpSizeEntry,
instead of GtkSpinButton. This avoids updating the spin-buttons'
adjustment values when they lose focus, truncating the value if it
can't be accurately displayed using the corresponding spin-button's
digit count. Since size-entries can have multiple spin-buttons
using different units, this prevents the value from changing when
entring a value using one unit, and then shifting the focus to, but
not changing, another unit.
GimpSpinButton is a drop-in replacement for (and a subclass of)
GtkSpinButton. Unlike GtkSpinButton, it avoids updating the
adjustment value when losing focus, unless the entry text has
changed. This prevents accidental loss of precision, when the
adjustment value can't be accurately displayed in the entry.
Note that libgimpwidgets already defines a (deprecated)
gimp_spin_button_new() function. This commit stays compatible with
the old function, by defining GimpSpinButton's _new() function as
gimp_spin_button_new_(), and defining a variadic
gimp_spin_button_new() macro, which expands to either the old or
the new function, based on the number of arguments, so that either
function can be used transparently as gimp_spin_button_new(). This
is all gone in master.
... and G_TYPE_INSTANCE_GET_PRIVATE()
g_type_class_add_private() and G_TYPE_INSTANCE_GET_PRIVATE() were
deprecated in GLib 2.58. Instead, use
G_DEFINE_[ABSTRACT_]TYPE_WITH_PRIVATE(), and
G_ADD_PRIVATE[_DYNAMIC](), and the implictly-defined
foo_get_instance_private() functions, all of which are available in
the GLib versions we depend on.
This commit only covers types registered using one of the
G_DEFINE_FOO() macros (i.e., most types), but not types with a
custom registration function, of which we still have a few -- GLib
currently only provides a (non-deprecated) public API for adding a
private struct using the G_DEFINE_FOO() macros.
Note that this commit was 99% auto-generated (because I'm not
*that* crazy :), so if there are any style mismatches... we'll have
to live with them for now.
Add an option to record a performance log through the dashboard.
The log contains a series of samples of the dashboard variables, as
well as the full program backtrace, when available. As such, it
essentially acts as a built-in profiler, which allows us to
correlate program execution with the information available through
the dashboard. It is meant to be used for creating logs to
accompany perofrmance-related bug reports, as well as for profiling
GIMP during development.
The sample frequency defaults to 10 samples per second, but can be
overridden using the GIMP_PERFORMANCE_LOG_SAMPLE_FREQUENCY
environment variable. Backtraces are included by default when
available, but can be suppressed using the
GIMP_PERFORMANCE_LOG_NO_BACKTRACE environment variable.
Logs are created through the new "record" button at the bottom of
the dashboard dialog. When pressed, a file dialog is opened to
select the log file, and, once confirmed, data is being recorded to
the selected file. Recording is stopped by pressing the "record"
button again (we use a highlight to indicate that recording is
active.)
While recording, the "reset" button is replaced with an "add marker"
button, which can be used to add event markers to the log. These
can be used to mark events of interest, such as "started painting"
and "stopped painting", which then appear in the log as part of the
sample stream. Markers are numbered sequentually, and the number
of the next (to-be-added) marker appears on the button. Shift-
clicking the button adds an empty (description-less) marker, which
is only identified by its number; this can be used when markers
need to be added quickly.
The log is an XML file, containing some extra information (such as
the output of "$ gimp -v", and symbol information) in addition to
the samples. The data in the file is delta-encoded to reduce the
file size, meaning that samples (as well as some other elements)
only specify the changes since the previous sample. This adds a
necessary decoding step before data can be processed; the next
commit adds a tool that does that.
There are currently no tools to actually analyze the data -- that's
still TBD -- but at least we can start gathering it.
Squashed commit of the following:
commit ee1ff7d502658cfa1248a13a3f0348495db07eda
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sun Jul 29 00:31:47 2018 +0900
Fixed that gimp-text-dir-ttb-* icons are lacked in Symbolic.
commit d87d012d697628da28fe90199cc04b95b72ba8ef
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sat Jul 28 16:23:10 2018 +0900
Fix a typo.
commit cf0238bf7df56c384cdf3b7ec69557d14740f853
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sat Jul 28 15:50:57 2018 +0900
Fixed seg fault error.
commit b07f60d06fa1a753fda5b4d46af01698c344154e
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Fri Jul 27 17:15:34 2018 +0900
Add support for vertical text writing.
https://gitlab.gnome.org/GNOME/gimp/issues/641
(cherry picked from commit 587d9bbb03)
In subdirs containing a generated foomarshal.h header, add the
generated sources to BUILT_SOURCES, so that they're generated
before the rest of the source files are built. Otherwise, since
there is no rule specifying the dependency between the rest of the
source files and foomarshal.h, and since foomarshal.h is not
checked into git (and hence doesn't exist when doing a clean
build), compilation of the said source files may fail if they're
built before foomarshal.h is generated.
(cherry picked from commit a5102a7dba)
- "LCh" intead of "LCH"
- "CIE LCh" instead of "CIELCh"
- "HSV Hue" instead of "Hue (HSV)" for all models/components
(cherry picked from commit 926dc070ef)
