This object holds the mapping of pad device features (buttons/rings/strips)
to actions, given the current mode (e.g. leds in the device), and can be
serialized/deserialized from configuration files.
These are not generic undo function, but specific to the resize case (and even
more particularly when calling the GimpItem's resize() class method).
Also the variable was wrongly named no_undo when it actually was meant for the
opposite meaning, i.e. when we want to push an undo for a resize() call. This
made the call harder to understand. Furthermore the usage of double negation did
not help with understanding the code.
Also added option in Edit->Preferences->"Tool Options"->"Paint Options
Shared Between Tools" that decides weather the options should be shared
between different tools.
When resizing drawable for dynamic layers, the resize drawable function
would push Modified Layer/Channel item to undo stack. Initially, I was
checking if the drawable is being painted upon and used it to disable
the undo, but this when using resizing layers with layer mask, even if
mask is being painted upon, we still want to resize the main layer and
vice versa. But the main layer is not being painted upon so it would
push the undo to stack. To prevent this, I was using
gimp_drawable_paint_start before resizing, but this method is very
inefficient, as this function duplicates buffers. So added a new member
to drawable->private that will store weather to push undo or not.
Added option to tool settings that will decide how newly created parts
of layer and layer mask should be filled. For layer, same options are
provided as present in "Set Layer Boundary Size" dialog. For layer mask,
first two options from "Add a Mask to the Layer" i.e. "White" and
"Black" are added.
This commit changes gimp_channel_resize function to actually use the
passed fill type instead of using hardcoded GIMP_FILL_TRANSPARENT.
Hardcoding this value if required should be done in function calling
this function (which is already the case with all the instances already
present afaik).
When painting with paintbrush tool, the borders of active layer will
automatically expand to accomodate the stroke. The undo does not work
with expanding layers.
This patch adds better handling for group begin and end markers
within ASE palettes. As a result, this fixes an issue where the last
color was not imported in some ASE files without groups.
Additionally, this guarantees that colors are imported using 4 bytes
per https://gitlab.gnome.org/GNOME/gimp/-/issues/10359#note_1921462
Resolves#10359
When compiled with -Werror=strict-aliasing, the build fails
on this line due to converting pointer datatypes.
This patch switches to using memcpy () instead.
This is only a temporary solution meant to be backported to gimp-2-10 branch,
so that at least the preview now matches how angles always worked in at least
the 2.10 series: angles are measured clockwise.
Now there is the question that in the documentation of the Brush Editor, it is
written that angles are supposed to be counter-clockwise. A solution was
proposed to make them so, but only for generated brushes (whereas angles stayed
clockwise for other types of brush) which is a very bad inconsistency.
Furthermore I find the whole tool options vs. brush editor settings mess quite
confusing. Some decision should be made for GIMP 3.
For GIMP 2.10 though, this should be an OK fix: no behavior change on-canvas,
only making the preview actually match what happens on-canvas (even though it
goes against what the docs say but it's probably better than breaking workflows
relying on actual on-canvas behavior).
Note: this commit is based on an initial proposition by Alx Sa in MR !1119,
except that the patch was only working when the preview needed to be scaled.
Instead we must go through this brush transformation code path for generated
brushes, whatever the scale.
Using gegl_parallel_distribute_area() for gimp_gegl_is_index_used() is just far
too slow by 2 order of magnitudes compared to a threaded implementation where I
process each buffer at once (but each in their own thread from a pool).
I guess the basic value check is too basic to warrant being done in threads
(note: even growing the distributed area by bumping the thread cost a lot was
not enough).
I didn't fixup commit dbaa8b6a1c directly so that we keep a trace of the
gegl_parallel_distribute_area() implementation in case we can do better later.
Additionally I fixed gimp_gegl_shift_index() to use the full drawable format,
including the possible alpha channel. Otherwise shifting indexes may result in
dropping the alpha value.
Until now, it was not really possible to delete a colormap color, but since we
now use GimpPalette, people would definitely try to do so. It just makes sense
to allow doing this, but only if the color is unused.
Additionally when we do this, all the pixels refering to bigger indexes will be
edited so that they continue to refer to the same color (bigger indexes are
shifted by -1). Therefore removing an unused color does not change the image
render.
I wondered if we might want more options, e.g. the ability to delete a color
without fixing indexes (i.e. that colors over the deleted color index would
shift to the next color). This would even allow to delete used colors (though
now the last index would have to be unused one, unless we cycle colors).
Yet I don't think this should belong to this basic API. The most expected
behavior when deleting a color from an image colormap is to fix all indexes
stored in pixels so that the image still shows the same. So that's what this
function will do in this generic usage.
This is meant to replace gimp_image_get_colormap() (see also #9477).
We likely won't need a gimp_image_set_palette() because we can simply edit the
image's colormap/palette with GimpPalette API now and it is directly updated.
For instance, the following code changes the first entry in the image palette to
red, immediately:
```python
i = Gimp.list_images()[0]
p = i.get_palette()
c = Gimp.RGB()
c.r = 1.0
p.entry_set_color(0, c)
```
For this to work fine, I added a new concept to GimpData, which is that they can
be tied to a GimpImage (instead of a GFile). Image palettes are not considered
internals, they are just tied to their image, therefore they can be edited by
scripts/plug-ins.
Additionally with this commit, editing an image's colormap from libgimp API also
generates undo steps now.
Calling gimp_resource_delete() on a data with a file which was not stored yet
would fail on missing file as reported by Lloyd in a comment in #9976. We could
just special-case the code to make the already-inexisting case acceptable on
deletion, but there are a few more issues.
In particular gimp_data_create_filename() relies on actually checking file
existence on the file system. Therefore generating the file path too early
(before any possible rename, i.e. for uniqueness or other formatting need) would
easily generate duplicate paths (which means one of the data object would be
overwritten on exit). It's better to kinda *reserve* the set file path
immediately by saving the data file.
The only drawback I could see on saving early is possible I/O slowdown if a
script were to create many data, but I actually don't think it's a valid use
case (no script should likely create enough data files that we would notice a
slowdown, i.e. likely creating hundreds of data objects at once) anyway. So
let's go with it, at least for now.
It returns all the fonts (possibly more than 1) with a given name. I left the
function gimp_font_get_by_name() as a utility when one don't want to choose (or
is not able anyway, e.g. a script with minimal information), though I wondered
if we should not simplify with a single function (the new one, which is the
correct one now that it is possible to have several fonts with a given name).
It is easy to test with fonts named the same. For instance I could find 2
different fonts, both named 'Holiday'. This call in the Python console returns
both:
> Gimp.fonts_get_by_name('Holiday')
As part of this commit, I also implemented resource arrays (or subtype arrays)
as PDB arguments and return types.
I am using the same GimpDrawableChooser with an additional drawable_type
argument to only show the appropriate tab if we want to limit what can be
chosen.
None of our plug-ins actually use a GimpLayer or GimpChannel only arg so far,
but if we have some day, or if some third-party plug-ins want to have such arg,
now they quite easily can!
Similarly to the various GimpResource select PDB calls, this allows to call a
core dialog in order to choose a drawable which will be returned back to the
calling plug-in.
This new GimpPickableSelect dialog is a subclass of GimpPdbDialog and uses the
same GimpPickableChooser widget as GimpPickablePopup, except that since it's
inter-process window management, it is harder to make a popup positioned
accurately relatively to a parent (especially on Wayland). This is why it's a
separate widget as a simpler dialog (which we will still try to make transient
as much as possible across platforms).
Brush, font, gradient, palette and pattern choices are currently chosen through
a dialog created by the core, which then returns the user choice to the calling
plug-in. This has the unfortunate consequence of having a pile of likely at
least 3 windows (main GIMP window by core process, plug-in window by plug-in
process, then the choice popup by the core process) shared in 2 processes, which
often end up under each other and that's messy. Even more as the choice popup is
kinda expected to be like a sub-part of the plug-in dialog.
So anyway, now the plug-in can send its window handle to the core so that the
resource choice dialog ends up always above the plug-in dialog.
Of course, it will always work only on platforms where we have working
inter-process transient support.
Having windows ID as guint32 is a mistake. Different systems have
different protocols. In Wayland in particular, Windows handles are
exchanged as strings. What this commit does is the following:
In core:
- get_window_id() virtual function in core GimpProgress is changed to
return a GBytes, as a generic "data" to represent a window differently
on different systems.
- All implementations of get_window_id() in various classes implementing
this interface are updated accordingly:
* GimpSubProgress
* GimpDisplay returns the handle of its shell.
* GimpDisplayShell now creates its window handle at construction with
libgimpwidget's gimp_widget_set_native_handle() and simply return
this handle every time it's requested.
* GimpFileDialog also creates its window handle at construction with
gimp_widget_set_native_handle().
- gimp_window_set_transient_for() in core is changed to take a
GimpProgress as argument (instead of a guint32 ID), requests and
process the ID itself, according to the running platform. In
particular, the following were improved:
* Unlike old code, it will work even if the window is not visible yet.
In such a case, the function simply adds a signal handler to set
transient at mapping. It makes it easier to use it at construction
in a reliable way.
* It now works for Wayland too, additionally to X11.
- GimpPdbProgress now exchanges a GBytes too with the command
GIMP_PROGRESS_COMMAND_GET_WINDOW.
- display_get_window_id() in gimp-gui.h also returns a GBytes now.
PDB/libgimp:
- gimp_display_get_window_handle() and gimp_progress_get_window_handle()
now return a GBytes to represent a window handle in an opaque way
(depending on the running platform).
In libgimp:
- GimpProgress's get_window() virtual function changed to return a
GBytes and renamed get_window_handle().
- In particular GimpProgressBar is the only implementation of
get_window_handle(). It creates its handle at object construction with
libgimpwidget's gimp_widget_set_native_handle() and the virtual
method's implementation simply returns the GBytes.
In libgimpUi:
- gimp_ui_get_display_window() and gimp_ui_get_progress_window() were
removed. We should not assume anymore that it is possible to create a
GdkWindow to be used. For instance this is not possible with Wayland
which has its own way to set a window transient with a string handle.
- gimp_window_set_transient_for_display() and
gimp_window_set_transient() now use an internal implementation similar
to core gimp_window_set_transient_for(), with the same improvements
(works even at construction when the window is not visible yet + works
for Wayland too).
In libgimpwidgets:
- New gimp_widget_set_native_handle() is a helper function used both in
core and libgimp* libraries for widgets which we want to be usable as
possible parents. It takes care of getting the relevant window handle
(depending on the running platform) and stores it in a given pointer,
either immediately or after a callback once the widget is mapped. So
it can be used at construction. Also it sets a handle for X11 or
Wayland.
In plug-ins:
- Screenshot uses the new gimp_progress_get_window_handle() directly now
in its X11 code path and creates out of it a GdkWindows itself with
gdk_x11_window_foreign_new_for_display().
Our inter-process transient implementation only worked for X11, and with
this commit, it works for Wayland too.
There is code for Windows but it is currently disabled as it apparently
hangs (there is a comment in-code which links to this old report:
https://bugzilla.gnome.org/show_bug.cgi?id=359538). NikcDC tested
yesterday with re-enabling the code and said they experienced a freeze.
;-(
Finally there is no infrastructure yet to make this work on macOS and
apparently there is no implementation of window handle in GDK for macOS
that I could find. I'm not sure if macOS doesn't have this concept of
setting transient on another processus's window or GDK is simply lacking
the implementation.
… is set.
The order for thumbnail creation in gimp_imagefile_create_thumbnail() is now:
1. If there is a GimpThumbnailProcedure, it is run first.
2. Otherwise we check if a thumbnail is in the metadata.
3. As last resort, we just load the full image.
Part of the fix was to copy gimp_image_metadata_load_thumbnail() into the core
code. I have been wondering if we could not drop the same function from libgimp
and remove the GimpThumbnailProcedure frome file-jpeg, since it just uses the
metadata thumbnail and it is the only plug-in using this code.
Also it is much faster to run this in core and it's generic function which makes
thumbnail loading from Exif data working for every format supported by Exiv2.
On the other hand, the file-jpeg thumbnail procedure also gathers a few more
useful information, such as the color model (in a reliably manner, since based
on JPEG header, unlike from metadata which may be wrong).
This is not the main reason for the specific output in #9994. These ones are
more probably because of similar usage in GTK (which updated its own calls to
g_file_info_get_is_hidden|backup() in version 3.24.38). But we should likely
also update the various calls we have to use the generic
g_file_info_get_attribute_*() variants.
To be fair, it is unclear to me when we can be sure that an attribute is set.
For instance, when we call g_file_enumerate_children() or g_file_query_info()
with specific attributes, docs say that it is still possible for these
attributes to not be set. So I assume it means we should never use direct
accessor functions.
The only exception is that I didn't remove usage of g_file_info_get_name(),
since its docs says:
> * Gets a display name for a file. This is guaranteed to always be set.
Even though it also says just after:
> * It is an error to call this if the #GFileInfo does not contain
> * %G_FILE_ATTRIBUTE_STANDARD_DISPLAY_NAME.
Which is very contradictory. But assuming that this error warning was
over-zealous documentation, I kept the direct accessors since they are supposed
to be slightly more optimized (still according to in-code documentation) so
let's priorize them when we know they are set for sure.
Per @Wormnest comment on ACB palette loading,
g_utf16_to_utf8 () now uses the string length rather than -1 to prevent malicious non-NULL terminated strings.
The new parasite format cannot be loaded by old versions of GIMP. This means we
must bump the XCF version (even though technically we didn't really touch the
XCF format itself because text layers are stored in a hackish way, yet text
layers are just too important nowadays to not care).
Nevertheless if an old XCF with text layers was loaded and the text layers left
untouched, the old parasite will be saved back as-is. Therefore no need to bump
the XCF version in this specific case. Only when we created new text layers or
edited existing ones.
In GimpText, The font used to be stored as a string containing its name,
Now, it is stored as a GimpFont object, which makes more sense and makes
operations on fonts easier (such as serialization).
Filling with Middle Gray requires getting the image format
for conversion from CIE Lab. This works when filling a layer,
but new images are not yet available in the context.
This adds the image to the context before gimp_drawable_fill ()
is called so it has access to the image format.
in gimpchannel-select.h
Looking at the version in gimpchannel-select.c, the calls made to it,
and also what is usual, the corner_radius_x should be before
corner_radius_y.
Found looking at the cppcheck logs.
The way we were creating a GimpData identifier was simply wrong, because it was
based on the assumption that the source file uniquely identifies a GimpData (cf.
gimp_tagged_get_identifier() which clearly says that the returned string must
uniquely identify this data). The very simple counter-examples for why this is
a mistake to consider a data file to be a good unique identifier are collection
files. For instance, TTC files (TrueType Collection) contain multiple fonts.
Instead I am adding the concept of "collection" with the assumption that
**within a given collection**, data names are unique (I do hope this to be and
stay true). So I add gimp_data_get_identifiers() and gimp_data_identify() to get
identifiers and check for identity.
The collection will use the old implementation of gimp_data_get_identifier()
because it is quite nice to have paths relative to data and config directories
(it allows some cases of data relocation without losing data identification).
The new implementation to compute a GimpTagged identifier on the other hand will
construct a string from the quality of being internal or not, the data name and
its collection.
Note that there is a `container_obsolete` too in GimpDataFactory and I don't
apply the "unique-name" property to it because I'm unsure what it is.
Furthermore, eventually we'll want all types of data to allow duplicate names
(brushes, patterns or whatnot may come from all sources and may be named the
same by different people). But for now, let's focus on fonts before breaking
other parts of the codebase which we might not look into right now.
Remap font names to unique generated names
so that pango sees them.
keep the font name for display and the internal
name for everything else.
* Fonts are still broken When exporting to pdf
* Not sure if xcf files would be usable on other systems
maybe use hash of psname internally instead
* Not sure if plug-ins using text layer work correctly
(do they use internal font name or the actual name?)
This is definitely not core type material. Also it's much better in the proper
header gimpimage-snap.h and the type name should reflect the file namespace,
especially as we make it public.
We had the following warning:
In function 'make_remap_table',
inlined from 'gimp_image_convert_indexed' at
../../gimp/app/core/gimpimage-convert-indexed.c:1057:7:
D:/msys64/mingw64/include/glib-2.0/glib/gmem.h:261:19: warning: argument 1
range [18446744071562067968, 18446744073709551615] exceeds maximum object
size 9223372036854775807 [-Walloc-size-larger-than=]
This is apparently caused by inlining in combination with using a signed
int.
See also: https://gcc.gnu.org/bugzilla//show_bug.cgi?id=85783
Casting to (guint) silences the warning here.
Resolves issue with #8461.
This provides a conditional value for the fill options to only show
a color and pattern, rather than fore/background colors.
Currently only used for the text editor.
Since MR !706, (style solid) doesn't exist anymore which makes gimprc parsing
fails (hence losing configuration).
This fixes:
> Gimp-Config-Message: 21:20:21.018: Error while parsing '/home/jehan/.config/GIMP/2.99/gimprc' in line 18: invalid value 'solid' for token style
> Gimp-Config-Message: 21:20:21.018: There was an error parsing your 'gimprc' file. Default values will be used. A backup of your configuration has been created at '/home/jehan/.config/GIMP/2.99/gimprc~'.
Replaces "Solid Colors" option in Fill Path with Foreground/Background
Colors options. This allows users to fill with either, rather than
having to switch the foreground color each time.
GIMP_CONTEXT_PROP_MASK_BACKGROUND was added to the fill and stroke
contexts to allow the background color to be recognized.
In places where Solid Color was used as a default, Foreground Color is
now used instead.
