Commit Graph

1283 Commits

Author SHA1 Message Date
Jehan d493f0537f Issue #8900 and #9923: reimplementing GimpUnit as a proper class.
This fixes all our GObject Introspection issues with GimpUnit which was
both an enum and an int-derived type of user-defined units *completing*
the enum values. GIR clearly didn't like this!

Now GimpUnit is a proper class and units are unique objects, allowing to
compare them with an identity test (i.e. `unit == gimp_unit_pixel ()`
tells us if unit is the pixel unit or not), which makes it easy to use,
just like with int, yet adding also methods, making for nicer
introspected API.

As an aside, this also fixes #10738, by having all the built-in units
retrievable even if libgimpbase had not been properly initialized with
gimp_base_init().
I haven't checked in details how GIR works to introspect, but it looks
like it loads the library to inspect and runs functions, hence
triggering some CRITICALS because virtual methods (supposed to be
initialized with gimp_base_init() run by libgimp) are not set. This new
code won't trigger any critical because the vtable method are now not
necessary, at least for all built-in units.

Note that GimpUnit is still in libgimpbase. It could have been moved to
libgimp in order to avoid any virtual method table (since we need to
keep core and libgimp side's units in sync, PDB is required), but too
many libgimpwidgets widgets were already using GimpUnit. And technically
most of GimpUnit logic doesn't require PDB (only the creation/sync
part). This is one of the reasons why user-created GimpUnit list is
handled and stored differently from other types of objects.

Globally this simplifies the code a lot too and we don't need separate
implementations of various utils for core and libgimp, which means less
prone to errors.
2024-08-02 10:46:38 +02:00
Alx Sa 2e6938b3da app: Rename app/core GimpVectors vectors API...
...to path.
Changes the names of
gimp_vectors_* () API to
gimp_path[s]_* (). Renames related files
to [path] instead of [vectors], along with
relevant enums and functions.
2024-07-13 05:07:57 +00:00
Alx Sa e8df68fb65 libgimp, app, pdb: Rename GimpVectors to GimpPath
This commit renames the GimpVectors
object to GimpPath in both app/core and
in libgimp. It also renames the files
to gimppath.[ch] and updates the relevant
build and translation files.
There are still outstanding gimp_vectors_* ()
functions on the app side that need to be renamed
in a subsequent commit.
2024-07-12 06:16:25 +00:00
Jehan d55325829f app: no more GimpRGB/GimpHSL/GimpHSV usage in paint code at all anymore.
I'm a bit unsure about the GimpMyBrushCore which doesn't have much
indication on which color space we are working in, but the new code
should not be worse than the old one (if wrong, color-wise, it should be
the same wrong as before).
2024-02-11 23:28:03 +01:00
Jehan fcfb574715 app: get_paint_params() now uses GeglColor. 2024-02-11 23:28:03 +01:00
Jehan c892de85df app: port some of the paint and fill code to GeglColor. 2024-02-11 23:28:03 +01:00
Jehan ce887767e7 app, libgimpconfig: color history is now space-invaded.
I also changed a bit the new color serialization by adding a (color …)
symbol framing the contents, for cases where we don't have a specific
property name, e.g. for the color history list stored in colorrc, unlike
for GimpConfig GeglColor properties.

While doing this, I moved GeglColor property deserialization code into
gimp_scanner_parse_color() which is now able to recognize both older
(color-rgb|rgba|hsv|hsva with no color space) and newer serialization
formats ("color", color model agnostic and space aware).
2024-02-11 23:28:03 +01:00
Jehan b6856af9d8 app: GimpGradient now uses GeglColor.
I still see some limitations in GimpGradient, and in particular, they are still
always stored as RGB in GGR files. It would be nice if we could store the actual
color format. This way, if someone chooses a gradient stop as Lab or CMYK color,
that's what the gradient file would keep track of. But also even storing the
space of a color (instead of storing/loading always in sRGB, even though this
may still work fine as we store unbounded double values). This might warrant for
a v2 of GGR file format.

This commit also fixes loading of SVG gradient which was apparently broken
regarding hexadecimal color parsing.

Finally I improve gegl_color_set_alpha() by adding an alpha channel when the
initial format had none.
2024-02-11 23:28:03 +01:00
Jehan dbbcfb16d5 app, libgimp*, pdb, plug-ins: GimpContext is now using only GeglColor.
- app: gimp_context_get_(foreground|background)() are now returning a GeglColor.
- libgimp: PDB functions named similarly in libgimp are returning a newly
  allocated GeglColor too.
- A few other PDB functions (the ones using these functions) were updated and
  their signature changed to use GeglColor too, when relevant. Plug-ins which
  use any of the changed libgimp functions were fixed.
- GimpContext: signals "(foreground|background)-changed" are now passing a
  GeglColor.
- libgimpconfig: new macro GIMP_CONFIG_PROP_COLOR using gegl_param_spec_color().
- GimpContext: properties "foreground" and "background" are now GeglParamColor
  properties.
- app: All code interacting with GimpContext objects were updated to receive a
  GeglColor (that they may still convert, or no, to GimpRGB for now).
- app: gimp_prop_gegl_color_button_new() was added as an alternative to
  gimp_prop_color_button_new() when the property is a GeglParamColor. Eventually
  the former should replace completely the latter.
- libgimpwidgets: gimp_prop_color_area_new() now works on GeglParamColor
  properties only.
- libgimp: gimp_procedure_dialog_get_widget() will generate a GimpColorArea for
  GeglTypeParamColor arguments.
2024-02-11 23:28:02 +01:00
Jehan ef8ddd7e30 app: rename the new gimp_drawable_*_undo() functions.
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.
2023-11-25 21:43:08 +01:00
Jehan aa7d7badc8 app: do not leave out-layer artefacts when canceling painting with layer expansion.
This is a fixup commit to MR !961, fixing a particular commit 5c2373a125 saying
that when canceling painting with layer expansion, strokes outside of the layer
remain visible.
2023-11-25 21:43:04 +01:00
Jehan e495fe7ede app: fix 2 GeglBuffer leaks and a profile leak. 2023-11-25 21:38:10 +01:00
Shubham 41e0151478 app: Make the layer auto expand options shared between tools
Also added option in Edit->Preferences->"Tool Options"->"Paint Options
Shared Between Tools" that decides weather the options should be shared
between different tools.
2023-11-25 16:19:43 +00:00
Shubham 5c2373a125 app: Cancel functionality works with dynamic layers
Canceling a paint stroke restores the layer and mask (if present) to the
original size if they were expanded during the stroke. The part of
stroke that is outside the layer remains visible though.
2023-11-25 16:19:43 +00:00
Shubham d49fcf9495 app: Always separate blobs_to_render and last_blobs in ink tool
In ink tool, if last_blobs is empty, the copy of blobs present in
last_blobs and blobs_to_render was same. Due to this, when layer
boundary is expanded, we move same blobs twice. Due to this a straight
line was drawn when starting painting from outside layer boundary. Fixed
the issue by storing a duplicate version in blobs_to_render. Updated
free part accordingly.
2023-11-25 16:19:43 +00:00
Shubham 2a41fc7ee4 app: Blink lock when layer expansion is prevented by lock
In layer expansion if user is trying to draw outside the layer boundary
with expand option turned on but the "Lock position and size" enabled,
the lock square will be blinked. If user is painting on layer mask, the
corresponding layer's lock will be blinked. It will be blinked only
once per stroke.
2023-11-25 16:19:43 +00:00
Shubham df9d1f54f8 app: Fix inefficient method of preventing pushing undo
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.
2023-11-25 16:19:43 +00:00
Shubham 6bfed5008f app: Add options to choose fill type of layer and mask when expanding
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).
2023-11-25 16:19:43 +00:00
Shubham 8bfa22b663 app: gimp_gegl_buffer_resize function can accept pattern to fill buffer
Modified gimp_gegl_buffer_resize function to add three new parameters,
pattern, pattern_offset_x and pattern_offset_y. If pattern is not NULL,
then we set the pattern of buffet to this value. Like in
gimp_gegl_buffer_resize function, this logic is mostly copied from
gimp_drawable_fill_buffer function with minor changes.
2023-11-25 16:19:43 +00:00
Shubham 841a195bb5 app: Fix broken strokes with the ink tool 2023-11-25 16:19:43 +00:00
Shubham 9ccb027aaa app: Create gimp_gegl_buffer_resize function
This function returns resized version of the input buffer. It also takes
in a color argument. The layer background will be filled with this
color. Fill background logic is similar to gimp_drawable_fill_buffer.
2023-11-25 16:19:43 +00:00
Shubham 5ed04055f1 app: check for lock_position of layer when editing its mask
The lock in the layers tab only sets lock for the actual layer and not
for its mask, so also check the lock on the actual layer and not just on
the mask when editing layer mask.
2023-11-25 16:19:43 +00:00
Shubham 5b8f410342 app: Fix layer expansion using MyPaint Brush tool with symmetry enabled 2023-11-25 16:19:43 +00:00
Shubham 960eaf0bc9 app: Ensure undo everytime layer expands while painting
Everytime the layer expands, if the undo extents are empty, then make
them non zero. If the undo extents are zero, then user will not be able
to undo the expansion of the layer. This is perticularly required by
MyPaintBrush as just clicking the image without any motion does not draw
anything, but expands layer if required.
2023-11-25 16:19:43 +00:00
Shubham b291a32a24 app: Layer expansion with MyPaintBrush now works.
Added tool option like other tools.
2023-11-25 16:19:43 +00:00
Shubham 5fdee7c5e7 app: gimp_paint_core_expand_drawable will return boolean
This function returns TRUE if the drawable is expanded. Otherwise, it
will return FALSE. This removes the need to check width and height of
the drawable to infer the same.
2023-11-25 16:19:43 +00:00
Shubham 3ccec0b128 app: Layer expansion while painting now works with layers with mask
When painting the layers with a layer mask, if the layer need to be
expanded, the layer mask is also expanded with it. The same is done even
if layer mask is being painted upon.

Undo works with these layers by adding resizing of both the layer and
mask to the undo group if the layer is resized during painting.
2023-11-25 16:19:43 +00:00
Shubham 5191c17fb7 app: Fix layer expansion while painting with symmetry enabled 2023-11-25 16:19:43 +00:00
Shubham e33618a650 app: Layer expansion while using ink tool
Now layers will expand when trying to draw beyond layer borders with ink tool.
Tool options similar to paint tools have been added (expand_use and
expand_amount).
2023-11-25 16:19:43 +00:00
Shubham 97a2627867 app: Do not expand beyond image borders while painting
When painting with "Expand Layers" option turned on but "show all"
turned off, layer will not expand beyond image borders.

Layer will not expand if "Lock size and postion" is turned on.
2023-11-25 16:19:43 +00:00
Shubham 4a953e5b59 app: Separate function for layer expansion while painting
Created a separate function gimp_paint_core_expand_drawable that handles
layer expansion while painting. The gimp_brush_core_get_buffer function
now uses this function to expand drawable. It has been separated so that
it can be reused for ink tool.
2023-11-25 16:19:43 +00:00
Shubham 9707a87488 app: Add options for tools which make layers expand
Added a checkbox that decides weather tool should expand layer when
crossing layer border and a scale that decides by what amount should
layer expand.
2023-11-25 16:19:43 +00:00
Shubham becb23c926 app: Make undo work when layers are expanded during painting
Undo now restores layer to original size if it was expanded while
painting.
2023-11-25 16:19:43 +00:00
Shubham ae7d37ebbd app: Make layers expand when painting with paintbrush tool
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.
2023-11-25 16:19:43 +00:00
Alx Sa b68a86e486 paint: Don't paint with gradient if dynamics not enabled
Resolves #10262.

The gradient color was being used if Confetti or Color from Gradient
dynamics had been set, even if dynamics had been disabled.
This adds an additional check to make sure dynamics are enabled
first - otherwise, the brush's existing stamp or color is used to paint.
2023-11-02 11:19:16 +00:00
Shubham a7379664e9 app: Fix extra drawing with airbrush tool on layers with offset
When using airbrush tool, if the layer has a offset, then the offset was
applied to the the coords multiple times creating a series of dots when
holding the airbrush still (from the gimp_airbrush_stamp function).
Fixed this problem by storing the original value of coords before it
gets updated.
2023-07-24 15:55:30 +00:00
Shubham 8463544502 app: fix broken symmetry on offset layers
Painting with symmetry enabled on layers with offset was broken. Fixed
it.
2023-07-24 15:55:30 +00:00
Michael Natterer 26dce72d2c Remove autotools 2023-05-27 00:03:52 +02:00
Michael Natterer 7ada432690 app: big porting of weak pointers to g_set,clear_weak_pointer()
This started as review of weak pointers, but using
g_set_weak_pointer() and g_clear_weak_pointer() is almost always
better, and shorter.
2023-05-22 18:16:09 +02:00
Michael Natterer 4d38ae333a app: remove the weak pointer GimpPaintOptions->brush in dispose() 2023-05-22 03:39:52 +02:00
Michael Natterer 2de78e45b6 app: some formatting in gimppaintbrush.c 2023-05-22 03:39:52 +02:00
Alx Sa 769e36d7cf core: color pick in image's RGB space
Replaces GimpPickableInterface's pixel_to_srgb () functions with
pixel_to_rgb(). Now GimpRGB's values should be in the correct
image color space from the beginning of the process.
2023-04-23 22:03:29 +00:00
programmer-ceds 0c89be5f06 Smudge problem on offset layers (fixes #8999) 2023-01-09 22:37:37 +00:00
programmer-ceds 8a066f0430 Strokes on offset layers are offset - fixes issue #8767 2023-01-09 20:57:26 +00:00
Jehan 9a2f5b0709 app: rework and fix the logic for copy-pasting multiple drawables.
There were a lot of incertainty of what should happen when we copy layers being
descendant of each other (i.e. when you select a group layer and some of its
children), then when you paste such data. So we sat down with Aryeom and tried
to come up with some consistent behavior which is somewhat expectable, but also
which would allow the most use-case.

Otherwise it was making very weird result when pasting the data, duplicating
some layers and whatnot, which was obviously a buggy behavior and never the
expected result.

We decided that if you select one leaf item, then even if you also selected a
parent item, it would be as though the parent was not selected. This is very
often what you expect anyway when you select a whole bunch of layers and would
work well if, say, you shift-click over many layers in sub-groups. Then you
wouldn't have to manually ctrl-click to unselect every group.

Then what if you were instead expecting to copy many groups? Then you could
shift-click the group arrow, closing all same-level groups. Once they are all
closed, you can shift-click the groups to only select group layers, not their
contents.

This way, both use cases are still quite doable easily with this default choice.
2022-11-12 18:28:58 +01:00
Jehan ca230cb770 meson: fix warnings of deprecated features.
Now that we bumped our meson requirement, meson is complaining about
several features now deprecated even in the minimum required meson
version:

s/meson.source_root/meson.project_source_root/ to fix:

> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead.

s/meson.build_root/meson.project_build_root/ to fix:

> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead.

Fixing using path() on xdg_email and python ExternalProgram variables:

> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead

s/get_pkgconfig_variable *(\([^)]*\))/get_variable(pkgconfig: \1)/ to
fix:

> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': dependency.get_pkgconfig_variable. use dependency.get_variable(pkgconfig : ...) instead
2022-08-31 01:29:37 +02:00
Jehan ccbf3c4bb0 app, libgimp*: add various stamp files to CLEANFILES.
Fixes:

> ERROR: files left in build directory after distclean:
2022-08-01 23:34:50 +02:00
Jehan 83e465ec16 app, libgimp*: updating autotools script in sync with meson.
Generated *enums.c now have an additional stamp no-op header include
(see last 2 commits). Sync this change into the autotools generation
scripts to prevent back and forth useless generation of these files each
time we switch from one build system to another.
2022-08-01 20:00:01 +02:00
Jehan 979acaaae2 app, libgimp*: commit the newly generated *enums.c files.
They are nearly the same as initially, except that now they include an
intermediate stamp header which will be generated by the build system.

The only 2 enums which don't need these includes (and are not versioned)
are libgimp/gimpenums.c and libgimpthumb/gimpthumb-enums.c.
2022-08-01 20:00:01 +02:00
Jehan 106f2a061d Issue #8145: meson: generation of '*-enums.c' files.
Our meson build system was not properly building the enums.c file,
because they are versionned.

I did a similar trick as what I did for the pdbgen, which is that I used
a wrapper script around the existing perl script, which sets proper
options and generate a stamp file in the end (which is considered by
meson as the actual custom target, not the C file since it is generated
in the source dir).

The most important part is that the stamp file is a generated header
source (not just a random text file) which is **included** by the
generated C file. This is what will force meson to regenerate the C file
if the header is updated, **then** build using this new version, not use
an outdated versionned version (which would make for hard to diagnose
bugs), through the indirection of the intermediate stamp header.

See #4201.
See also: https://github.com/mesonbuild/meson/issues/10196#issuecomment-1080742592
2022-08-01 19:59:53 +02:00