In addition to the port, mnemonics were added to both file-pdf-save-multi
and file-pdf-save's GUI parameters.
Some runtime warnings were also fixed, such as trying to use a NULL string
parameters to make a file and trying to access properties from file-pdf-save
that don't exist in file-pdf-save-multi.
As shown in a video for issue 11087, some system themes
may add a white box-shadow on the side of unselected
tabs. This patch forces box-shadow to "none" to prevent
this.
Resolves #11057
Per Idriss Fekir's research, data from GBytes
should be written before the GByte is freed.
Perhaps due to luck, the data persisted on
Windows but was freed too early on Linux.
This patch should resolve the issue.
Resolves #11083
Per bootchk, changes in function calls to
palette_entry_get_color () and
gradient_segment_get_left_color () were
broken in Python scripts due to GelColor
being used post Color Space Invasion.
This patch fixes the calls and returns.
More descriptive name for script-fu-interface-dialog
Delete SF flag for gimp_ui_init already called: gimp_ui_init can be called often.
FUTURE: might be faster to call just gegl_init when mode is non-interactive.
After the color space invasion, the
Clip Warning filter no longer had color
areas for its shadow, highlights, and
bogus color properties. This patch ports
them to GeglColor so the widget can be
created correctly.
GimpRGB structs are also converted to
GeglColor in GimpPanedBox and two
plug-ins.
Otherwise we are not in a valid position anymore and further loading the XCF
fails. This may happen when updating a GEGL operation (in particular removing
effect properties, or renaming them).
The two threshold color pick buttons needed to have
a GeglColor parameter for their GimpPickerCallback
rather than a const GimpRGB.
This also fixes a crash caused by trying to free the GeglColor
rather than unreferencing it.
Without this, there is no easy way to quietly check for existence of a resource by name.
Needed when plugin authors can name defaults for resource args by name.
Add tests to script-fu/test/tests
Mainly fixing GimpRGB comments and
parameters that are unused (or in unused
functions).
GimpCircle and GimpGradientChooser
have color conversions ported to use
GeglColor exclusively.
Since commit 10b96b1025, we had buffer leaks as soon as we ran filters.
gimp_drawable_get_buffer_with_effects() was either creating a new buffer (when a
drawable had filters) or not. And calling code couldn't know which is which.
Code needs to be consistent. Either we return a new reference to take ownership
to, or not. So let's change to add a new reference to the drawable' buffers so
that it always returns a new reference to free.
So far, we did not consider that group layers could also be part of
a set of layers that have clipping set. This means that clipping groups
can be nested.
To support this we have completely rewritten the layer parser to detect
all clipping groups and mark them in a first pass. We now go through
the layers from the last (top) layer to the first (bottom) in this
first pass, because that makes it easier to detect the start/end
pairs of a clipping group.
In the second pass we handle the clipping groups first before adding
layers, except when a regular group is also the start of a clipping
group. In that case we need to handle the clipping after creating the
regular group, or we get an incorrect order.
Unsupported psd layers were dropped when loading psd images. This
causes problems when handling psd clipping groups, see issue #8453.
PSP also does not drop unsupported layers, so let's keep the layers
and accept that they will usually show up empty. This will help in
fixing clipping groups in a next step.
While we are at it, also remove the warnings that are only shown when
define CONVERSION_WARNINGS is TRUE (defaults to FALSE). We already
have a better way to show unsupported features, so at least for the
unsupported layers it is not needed anymore.
There are still some CONVERSION_WARNINGS warnings left over in the
blend modes conversion, which do not have a similar warning in our
unsupported features dialog.
* Makes the wording more concise and "first contributor-friendly"
+ Adds info about submitting patches
* Makes the explanation of use cases implicitly mandatory
+ Adds discuss info to facilitate the redation of use cases
This commit unites two scripts (.sh + .bat) in one .ps1. PS was choosed, since:
1) We don't need MSYS2 to distribute with Inno at first. Now, who wants to
just distribute GIMP can do it easier natively without a separate environ.
2) PS is actually pretty solid and have a good number of cmdlets, unlike the
ancient CMD, which barely supported more than 9 parameters in .bat files.
Consequently, some redundant variable checks have been removed from the .ISS.
Also, changes the name of the job and script for better consistency with the
upcoming MS Store job.
Though commit a14caafa8c was not wrong per-se, it's a bit too much. ;-)
Functions like g_ascii_dtostr() already exists for this very purpose of
converting a double/float to string in a locale-independent format.
CSS breaks when given a number with a comma as the radix
instead of a decimal. Depending on the system localization,
printf () may return numbers in this format when resizing
the font. This causes the theme to break unless font size is
set to 100.
To prevent this issue, we create the font size string manually
using integer division and mod operations.
- Replaces GimpRGB in Channel Dialog
with gdouble array, as was done in
channel_options_color_changed ()
- Replace %ld with G_GSIZE_FORMAT
in libgimp checkboard color message to
fix warning in Windows build
- Set file-gih documentation text as
translatable.
I think I may even have been the one who suggested to make this checkbox always
visible, but after more thought and usage, I just realize that this option is
not about showing the Welcome dialog, but about showing the Create tab of the
Welcome dialog. So I move it to the Create tab.
A very obvious case where the previous option location could have been
considered wrong is that we will always show the dialog (on the "Welcome" tab)
for updates, even if this checkbox had been unchecked. So if we left it as a
global option of the dialog, this could be considered a bug (the option is
disabled, but the dialog still opens on updates), whereas the new position and
shortened label make it clearer that this settings only apply to whether or not
we show specifically the Create dialog on start.
The splash image had a lot of empty space around it. From what I understood,
this is because we want to avoid it to be too big because it makes the dialog
overgrow the display size on small screens. But I don't think that was a very
good idea. We should find better ways to save space.
In d055564d, a pointer to the color profile
for NDE filter color properties was being
saved rather than the actual ICC profile.
This patch fixes the issue.
It also allows colors to load even if the
color profile is corrupted, with a warning.
Per bbb30eac, the GimpHSV object is replaced with
gegl_color_get_pixel () in "HSV double" color format.
GimpCellRendererColor still needs to be updated to
accept GeglColor rather than GimpRGB.
This commit fixes several issues with the plugin.
* Move plug-in to GimpProcedureDialog framework (see #9250)
* Use GimpPalette instead of (soon to be deprecated) Colormap (see #9477)
* Make plugin UI height, make it resizeable, update font sizes,
paddings, etc (see #10533)
Further improvements most likely are needed because plugin still uses
GimpRGB and GimpHSV (former is used by GimpCellRendererColor, latter for
H, S, and V values)
Resolves: https://gitlab.gnome.org/GNOME/gimp/-/issues/10533
Resolves: https://gitlab.gnome.org/GNOME/gimp/-/issues/10749
During the GimpProcedureConfigDialog port,
the "gimp-brush-pipe-parameters" parasite loading
code was unintentionally removed. This parasite
was used to restore the GIH parameters if it was
loaded as an image.
This patch restores that code on initial export as
GIH, then removes the parasite since the parameters
will be saved as part of the GimpProcedureConfig
going forward.
Allow (script-fu-use-v3) in script, or in SF Console.
Definitive description is in script-fu/docs/using-v3-binding.md
Makes SF interpret v3 of SF dialect.
- marshals single return value from PDB without wrapping in list
- marshals boolean return value from PDB as #t #f instead of integers
- marshals boolean to PDB from #t and #f or TRUE and FALSE
- marshals void return from PDB as () instead of (#t), but that is moot.
The version of SF dialect is distinct from the version of the PDB API.
Dialect v3 is opt-in: the initial dialect of all SF tools remains v2.
Commit also allows #t,#f for defaults of SF-TOGGLE instead of TRUE, FALSE
but that is an independent enhancement (but closely related.)
Affects interpreter state of the current process.
Not an attribute per se of a plugin.
While in this state, a plugin should not call PDB procedures
which are themselves v2 script plugins,
or a few utility scripts in script-fu-util.scm,
but that is rarely needed.
Does not remove symbols TRUE and FALSE from dialect.
A script can also call (script-fu-use-v2) to revert.
That is also discouraged but useful e.g. for testing.
Fixes #9883
There were menus that put their entries
directly in the tab menu rather than in a submenu.
This moves them to submenus to bring back GIMP 2.10 behavior.
Stray entries added by scripts are also moved to the right
submenu.
For improved readability, int or boolean types are used in place of
guchar for PDB parameters where the parameter description better fits
one or the other type.
This change affects `plug-in-alienmap2` and `plug-in-maze`.
Also, the problem with `guchar` parameters is that they currently cannot
be modified via `GimpProcedureConfig` due to the type not being
supported.
Call gimp_ui_init during query phase as well as run phase.
Maybe gimp_main() should do this.
Since space invasion from GimpRGB to GeglColor,
plugins that declare defaults for formal args of type GeglColor
need babl and gegl at plugin registration time.
The 'Docker' draft of GIMP was introduced in 09/04/2017 and then died ONE day
after, mostly because of "bad" timing (few years later we moved to GitLab CI).
Similar (in fact, even worse) than 'jhbuild' folder, update it to keep the
current development status is so hard that it is equal to do it from scratch.
So it is reasonable to delete it anyway.
Due to changes in our metadata handling API for plug-ins, the exif and
xmp metadata read from exr images was being overwritten by empty
metadata.
Fix this by following the new API and also add messages when loading
metadata fails. That way it will be easier to catch in the future if
metadata loading gets broken again.
When defining jpeg_exr a closing \0 is automatically added by the
compiler. So when we compare it using sizeof, we do not compare
6 bytes but 7. Since there won't be three 0's, this will fail.
Fix this by reducing the size by 1 and also update the comment to
make this clear and further to add that this was changed after
darktable 4.0.0.
gimp_metadata_set_from_exif has special code for handling old-style
GIMP exif parasite data, but didn't check for the more common case
of loading exif data from image formats that can't be handled by exiv2.
The exif data in these formats usually start with the TIFF endian
markers instead of "Exif", which caused a failure to read this
metadata for e.g. EXR images, see issue #10903.
We change this function to check for "Exif" at the start of the data,
in which case we assume it to be the old-style exif parasite and in
that case add extra metadata as was previously always done.
In all other cases, we do not add extra metadata.
These files are not deleted when the Unstable (GIMP 2.99) or Stable (GIMP 3)
version are installed because the root is different. So, they can be removed.
Resolves #11004
During the port to GimpProcedureDialog, the code
that assigned the current monitor object for
Windows and MacOS was accidentally removed.
This patch restores this code in the proper place.
At script create time, create a GimpRGB i.e. pixel from the declared name of default color.
At plugin procedure registration time, convert that pixel to GeglColor,
and use that color to declare the color arg using GeglParamSpecColor(default=color)
Fixes a faulty fix a few commits back where we lost the declared color name.
The proper dataflow is name->color->paramspec-with-default-color.
Extract methods related to color into new file.
So method names document what is being done.
So related code is together.
Ditto for resource.
No functional change.
Preparing for changes to reset/default and changes to representation of pixels
in lists of differing lengths rgb vs rgba.
Resolves #11003
GeglColor defaults to NULL rather than black like
GimpRGB. When selecting text with two or more colors
in the total selection, this causes NULL to be passed
to gimp_color_button_set_color () which throws an error.
This patch resolves the issue by setting GeglColor to
black if it's NULL before the call.
After the color space invasion, the
Semi-Flatten GUI was broken since it still
used GimpRGB as its color property.
This patch fixes this by porting to
GeglColor. The GimpRGB conversion was
also removed from the PDB interface
since the GeglColor comes directly from
GimpContext.
Resolves #10992.
GimpTextLayer's color attribute was
updated from GimpRGB to GeglColor,
but gimp-text-layer-set-color still passed
in GimpRGB. This patch updates the PDB
call to match the property type.
Fixes errors introduced by my prior commit c0ca0b74
1. SF is storing colors in GimpRGB, not GeglColor.
Storing using wrong pointer type seemed to work, but would not build on newer compilers.
2. spurious error message "CRITICAL....Two different plugins tried to register..."
Due to calling gimp_ui_init too early, in the class instance init.
When testing on Debian with acertain invalid PCX imagea that return
"Invalid number of bytes per line in PCX header", we get an error:
free(): double free detected in tcache 2
On Windows this doesn't cause an error, most likely due to a different
implementation of fclose.
The problem is that in case of errors fclose was called twice. Since
the file is opened outside the load_image functions, let's handle
closing also only outside that function.
In addition to that, change all g_message error notices to use
g_set_error instead, that way we always return a GError in case of an
error.
Further we also fix a possible error case of overwriting an existing
error by using g_prefix_error when the error is already set.
Resolves #10990.
Since the "mask-color" property is now a GeglColor,
we need to use gimp_prop_gegl_color_button_new ()
rather than gimp_prop_color_button_new () to
display it in the options panel.
Per @brunolopesdsilv, the About and Quit
dialogues had custom buttons which did
not receive the text-button CSS style.
This patch adds those back so the buttons
match the styling of the others in the
dialogue.
Previous pcx commit da217088d0 fixed
loading pcx images that had an off by one value for bytesperline.
However, it did not take into account that a value of 0 would be
invalid, causing a crash.
We fix this by adding a check for 0 and also failing in that case.
Since PDB now traffics in GeglColor instead of GimpRGB.
Change GimpParamSpecRGB to GeglParamSpecColor when declaring args to procedure.
Declared default is temporarily "black".
Change conversion of gvalue to scheme representation, now from GeglColor.
Incidental change to interpreter to init gegl early,
since now needed during registration phase.
Most of the C boiler-plate code is generated so that all you have to do is
implement the run() function with test code in it.
Also adding a README to make it all very clear and easy to add new tests.
With Python binding, it gets very easy to test new functions. I've been
wondering if we need C counterparts, but really since it's a GObject
Introspection binding, if a function succeeds there, it should also succeed in C
code.
For now, I'm testing a few of GimpPalette API. Not all of it yet. Also I test
both the direct C binding and PDB procedure since in some cases, one or the
other may not properly working. See #10885.
… accessed from Python.
Creating a new function gimp_value_array_get_color_array(). This should normally
not be needed (it isn't in C), but because of GObject Introspection limitation
and the fact that pygobject will automatically try to convert GValue to the
embedded value, we get this weird situation where the result is unusable in
Python for certain types. One of these types is GimpColorArray.
I suggest an annotation request to GObject Introspection:
https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/492
I think that with such annotation, followed as a second step by pygobject
support, correctly handling NULL terminated C arrays generically should be
feasible by bindings.
Resolves #10762.
Updates gimpdrawable-preview.c to use
gimp_drawable_get_buffer_with_effects (),
which includes any NDE Filters applied to
the layer in the preview.
The preview is also set to update when a
filter is applied non-destructively.
We were missing GimpColorArray support in one function. Note that the specific
example in Python in #10885 still doesn't work, but for a second reason:
gimp_value_array_index() returns a GValue which pygobject automatically tries to
transform to the contained data. And unfortunately it doesn't know about our
GimpColorArray type so we end with unusable boxed type generic data.
Since the Image Recovery dialog is blocking the main process (and requires an
answer to be done first), let's simply move down the Welcome dialog to after
this answer was given. This way, we simply won't have both dialogs in the same
time.
It was only used for the gimp-win-a64 job and was coming from MSYS2 repository
which already dropped it:
a98352b2ba
The first patch is still needed as the upstream fix is meant to appear in clang
18 according to bug report, yet our CI still uses clang 17.0.6. See:
https://github.com/llvm/llvm-project/issues/51286
Since the color space invasion, GimpRGB
properties do not create widgets anymore.
For Python plug-ins, we need to add
GeglColor properties as GObjects with
GeglColor value types as a workaround.
This patch does this and updates the
Foggify plug-in with the new datatype.
It is quite obvious that these were all kept around for the fun historical
background. And even though we can always get these back anytime through git
archeology, if these images disappear from our sight, we will just eventually
forget they even existed.
We now have a `gimp-data` repository for all data used and installed by GIMP. I
am not going to add these over there since it would go against the whole purpose
of splitting the source repository (we have too much data so we will want to
clone `gimp-data` as shallow so that it will only contain the necessary data to
install GIMP).
Yet I have created a page to reference and display all these original images
(and more! I spent quite some time researching old splashes and logos in our dev
log) for the pleasure of keeping the history of GIMP alive. It also reference
commit links for easy retrieval and further researches.
The only left images now are:
- gimp-logo.png and gimp-devel-logo.png: these are used in the About dialog or
API reference. Ideally they should be generated from the SVG source.
- gimp-splash.png: used as splash image, in the Welcome dialog and in the
Windows installer.
- wilber.png: only used in some Script-fu test scripts as far as I can see. This
should also be generated from the same source SVG as gimp-logo.png, or maybe
simply gimp-logo.png should be used instead.
Logos: https://gitlab.gnome.org/GNOME/gimp-data/-/blob/main/images/logo-log.md
Splashes: https://gitlab.gnome.org/GNOME/gimp-data/-/blob/main/images/splash-log.md
...with the Enter key. Combines the single image
and multi-image opening methods so that no matter
how you open recent images (single click, button, or
multi-select and pressing Enter), it opens all selected
images in the Welcome Dialog.
AFAIU the issue which it tried to fix only happens on custom builds and it looks
to me that it's just about multi-prefixes developer builds which were not
configured with -Drelocatable-bundle=no as they should.
When you compile GIMP yourself and intend to run it in a multi-prefix
environment, without ever relocating the build, like on Unix-like systems, then
disable this feature.
In any case, we should never do this kind of system file moving hacks in our
build system. The MSYS2 project even had to patch this out:
https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/1171#note_2022406
The indexed conversion code was originally written for very low-memory systems,
this makes the mapping it does quantized and noisy, for examples see issue
#5159 this commit removes quality/memory use trade-offs, modern machines can
take a 2-300mb temporary table allocation.
This is similar code to what I added for the Windows builds, except that here
it's because deps-debian-x64 will also end up feeding dev-docs job too.
Right now our tagged build of GIMP produces docs for unstable versions of babl
and GEGL.
Since !1171 we can use the CI scripts locally, but the initial implementation,
after some commits, revealed to be troublesome. So, now reworked to be simple.
As noted by Jehan, the way of defining the (many) GIMP versions can change.
So, let's take the GIMP version directly from the generated config.h file.
Also, changes the declaration of some variables to conform with "best pratices".
This list is referenced in the gimp-web-devel site, and my initial
implementation, in terms of ease to use, was a throwback.
Also, make the CI code more simple without changing the list file.
As noted in a comment on issue 10873,
choosing Selection for Fixed Gear throws
a TypeError. This is because with the change
from GimpRGB to GeglColor, we can no longer
directly access the red component with an index.
Instead, we need to call Gegl.Color.get_rgba() to get
that value, which is what this patch does.
Resolves #10882.
Before the color space invasion, INPUT_COLOR () returned
either a GimpRGB or NULL (if alpha == 0) that was used
directly in functions.
Now it's used to set a GeglColor in gegl_color_set_pixel (),
and calling that with a NULL color resulted in a Gegl-Critical.
This patch checks if INPUT_COLOR () returned NULL before
trying gegl_color_set_pixel () to prevent the issue.
The alternative solution would be to call:
> image_new_dialog_set (dialog, NULL, NULL);
This would have reset to default template. But it's still not exactly like the
"new image" action which defaults to the active image's size if there is an
opened image.
In order to avoid complicating the code further, as well as code duplication,
hence code divergence, let's call the "image-new" action, making sure that this
button will always behave exactly like the "File > New" menu item.
Then since we need to process the return value of this dialog (either re-showing
the welcome dialog in case of new image creation cancelation, or destroying the
hidden welcome dialog otherwise), I check for the singleton pointer and connect
the handlers to it.
Moreover I made the "response" signal of ImageNewDialog be handled as
G_CONNECT_AFTER otherwise we nearly never had the possibility to handle its
responses properly (because the base handler was doing it first, then often
destroying the dialog).
The rest of the time, we want to use HEAD of their main branches.
The last ctx update seem to have broken the CI build on Windows. While we'll
have to fix this, let's do this after we release GIMP.
Anyway we obviously don't want to use unstable code for actual point releases,
so it's a good thing that this made me think of adding such rules.
Use the same amount of dithering on R,G and B if they initially were all equal.
This allows us to keep achromatic gradients achromatic, while providing the
same amount of dither as before for colored gradients. Discrepancy uncovered in
issue #10756.
While the buffer used by Cairo may have a rowstride bigger than 3 * width, our
internally stored buffer has the exact size required for drawing the scale.
We were not properly duplicating the left and right colors when duplicating the
existing segments in gradient_editor_save_selection(). Therefore we ended up
freeing original GeglColor on exiting the GimpColorDialog.
Additionally to the reported crash, I add a few GeglColor freeing which were
leaked and some safeguard in gimp_gradient_get_flat_color() to ensure it always
returns a color (or raise a CRITICAL to be investigated easily).
Finally a few signals in GimpColorDialog had to be ensured disconnected when the
dialog is destroyed.
Our code expects that these GeglColor properties are always non-NULL in various
places, which may lead to crashes.
The property defaults should take care of this, and I am actually unsure why we
need to set it in the init(). Maybe the set_default() method for the GParamSpec
kicks in a bit late, while we have code syncing objects already running. I'm not
sure. It might need to be investigated later. But for now, let's simply make
sure we initialize the objects manually so that it's never NULL.
Issue #10756, without this grayscale pixels are affected by
the red part of the manipulation configuration, after this
change pixels with original saturation == 0.0 are only
changed by the master adjustment.
While doing this, I could find a lot of problems in the algorithm:
1. It looks like the original intent (from GUI and code) is that you set hue and
saturation but not really the intended lightness, rather its increase or
decrease, relatively to every pixel current lightness. I.e. that every pixel
will be set to the selected hue and saturation, and only the lightness will
change. The "lightness" field is therefore a relative value (pixel per
pixel). The first problem is that instead of lightness, we compute the
luminance, which is related but different and set this in the lightness
field.
2. The second issue is that we were using gimp_hsl_to_rgb() which after testing
(because its documentation doesn't give any TRC/space info at all) looks like
it computes a color from HSL to non-linear RGB of the same space. Yet we were
outputting to a linear RGB space. So we compute the wrong values. On the
other hand, because of the first problem, I realize (after testing) that it
makes our render closer to the intended render by chance (at least when the
TRC is sRGB's). It's still wrong, but if we were to change the output to
"R'G'B'A float" instead, the render would be much darker. In both cases, it's
wrong anyway.
I would not say that the 2 problems are canceling each others, but they are
making the final result somewhat OK.
3. Ideally we should be using babl to convert colors, and this is the best way
to actually implement the original filter intent. Unfortunately so far, doing
this is much slower (though I save a lot of time by moving out of the samples
loop and processing data in chunks, it's still slower than the current,
nearly instant, implementation).
4. Because of all previous implementation irregularities, the render is
different depending on the actual image space. I.e. that the exact same image
filtered through Colorize with the exact same operation parameters will
render differently. I would need to test further, and maybe it's normal since
HSL is also space-dependant (and that's where we work on in this operation),
but I'm wondering if the result should not be independant of the working
space.
5. I implemented our own prepare() method because the one in
GimpOperationPointFilter parent seems to allow other input or output models.
Even though in all my tests, it was always linear RGB (which is what we want
here), let's make sure by having a custom prepare() method explicitly setting
these. It's also the opportunity to create some babl fishes.
In any case, I'm leaving the code as-is for now, because it's how this operation
has been since forever (at least for as long as I was around) and I don't think
it's the right idea to change it on a whim.
This raises even more the concern of versionning GEGL operation, which we have
been discussing with pippin on IRC lately, because if ever we want to change
this one, now that operations are not just applied, but possibly
non-destructively recreated at load, we need to make sure that we recreate the
render expected at the time of creation of a XCF while allowing us to have the
filters improving when needed.
Resolves the main part of 10835. As nothing else can
be done in the GUI once all the filters are merged down
(and the GUI itself will be unavailable once closed until
a new filter is added), it makes sense to auto-close it.
gtk_widget_set_visible () was used rather than
gtk_popover_popdown () due to notes in the code about
buggy animations.
There is the possibility that users may want the GUI left
open to quickly undo the merge, so this should be
re-examined after feedback from the 2.99.18 release.
To reflect increased generality, its not just "coffee" but any gradient.
Delete "realistic looking": subjective and adds no content.
Better tooltips for the arguments.
Fix it by also enhancing, making the gradient an argument with a default
instead of a fixed choice of the gradient named "Coffee".
Instead of fixing by looking up the gradient ID in the body of the script.
Right now, I just transform any GeglColor return value into a RGB u8 triplet,
because that's also how we were supporting GimpRGB anyway, though it's seriously
limited.
Ideally we'd add some real concept of generic color abstraction in Script-fu
too, which could support any color model, space and precision.
Resolves #10848.
In cc62f2b0, we moved the filter property loading code
earlier in the process. However, the opacity, mode, and
region options for GimpFilterTool were not included in
this move, so they reset back to defaults each time.
This fixes that problem so settings are retained when
editing.
Resolves #10830
The supersample-max-depth parameter
of gimp-drawable-edit-gradient-fill
required a value between 1 and 9.
Previously this wasn't enforced, so several
scripts called it with a value of 0.
Now that it's enforced, those scripts were
broken. This fixes the calls in weave,
gradient-example, test-sphere, burn-in,
and coffee (although it has other issues)
It was a bit sad that we'd release GIMP 2.99.18 with no plug-in using
GeglColor argument yet, so at least with this, we'll have one as a demo
of what needs to be done.
- Make sure the led color is set at init().
- Unlike old GimpRGB code, values' colors must be set explicitly first.
- Make the Gimp object into a property (this one is not a problem right now, but
it's better this way).
- Don't assume the Gimp object is non-NULL. In current code, it is set to NULL.
The only consequence is that we don't use color management settings to draw
with Cairo. For this widget anyway, it feels unnecessary.
Altering the Warp tool's GEGL filter while it's being actively edited
causing a crash. More work will be needed to make these effects
work non-destructively - for now, we'll prevent users from raising or
lowering them from the NDE UI.
To simplify the logic, I created an `is_update` variable. This makes the code
much more understandable (and also simplify the redundant or over-complicated
imbricated `if` blocks).
The fix part is that the update check would have never happened for anyone
leaving the "Show Welcome Dialog" option checked, whereas we only want to bypass
the update check for new installations or updates.
Allows users to quickly configure themes and other
"controversial" options when first installed.
Also allows the welcome dialogue to appear on start,
depending on user preference.
… (u8), or CMYK is selected.
We always need a final NUL indicator in a GStrv. In these 2 cases, we might fill
all 6 first indexes, so we must have an array of size 7.
Since resources must now either belong to an image, or be tied to a file, or be
marked as internal, we must immediately save imported palettes, so that they are
tied to their file.
For the time being, only the same format as GimpRGB params is supported, which
means creating a color either as CSS strings or as RGBA list values, which means
that we can only input sRGB values right now in ScriptFu (even when calling
GeglColor-using API).
This is the second part to fix issue #10811.
Though I had already implemented passing GeglColor through the PDB, it was not
complete. In particular, the protocol was not able to pass GeglParamColor specs.
Fixes:
> LibGimp-WARNING **: 16:06:09.451: _gimp_gp_param_def_to_param_spec: GParamSpec type unsupported 'GeglParamColor'
This is part of the fix to issue #10811, though it's not complete yet.
Clicking on the Save button threw an exception as the wrong class was
used to invoke the `set_alternative_button_order_from_array()` method.
Since `Gtk.Dialog.set_alternative_button_order_from_array()` is
deprecated and the GIMP functions with the same name suppress
deprecation warnings in the C code, we suppress the warning here as
well. The `warnings.catch_warnings()` function is not thread-safe
according to the Python documentation, which should not pose a problem
here.
Also, the file chooser dialog now allows specifying a new file instead
of overwriting an existing file.
The current values_cmp() method will segfault if an object contains a NULL
GeglColor value. I fixed it in commit c0477bcb0 in GEGL, but since the GEGL
release is already done, I add this special-casing on GIMP side.
To be removed when we release and depend on GEGL 0.4.50.
The crash was happening when activating the text tool and raised in a comment of
another report: https://gitlab.gnome.org/GNOME/gimp/-/issues/10813#note_2009702
When changing the selected color, we have no reason to redraw the Z preview.
This preview should only be redrawn if the allocation size changed, or if we
change the previewed model or the Z component.
As for the XY preview, it should only be redrawn if the Z value is changed (and
of course, similarly, if the allocation changed or if model or Z component
changed).
With "HSVA" and a few others, the function was not returning the right value (it
could not see it was encoding alpha channel.
I had fixed it on babl directly with commit a28309c yet I had forgotten to push
it! Let's just add some #ifdef and a comment.
No custom conversion code anymore. This also fixes some bugs in HSV when
I was wrongfully multiplying the hue by 360 when mixing babl and custom
code paths.
It's actually not enough to get proper colors for inner text tags. The
main color is correct, but color for subtext is currently not managed.
This must be fixed.
In particular, the Curves, Levels and Operation tools method implemented
are updated. Also GeglColor arguments in GEGL operations are not
transformed into GimpRGB arguments anymore in GIMP. GeglColor GParamSpec
stay GeglColor now.
We don't try anymore to convert early from a pickable color to another
format/space. Now we are able to get a GeglColor and move it around,
doing only last-second (when needed) conversions.
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).
Until now we only had the case of the CMYK color selector using the
soft-proofing profile. Yet this is also interesting for other color
selectors, in particular to show out-of-gamut colors. Indeed if we
enable soft-proofing on the active image, it is interesting to show the
intersection of the current RGB/Grayscale space gamut with the
soft-proofing gamut.
Right now, this is only used in GimpColorSelect when showing colors in
LCh color space.
This is used for the gimp_color_is_perceptually_identical() function,
because the Euclidean distance in LCH is extremely limited, if not wrong
in many cases. Indeed LCH is not perfectly perceptually uniform, and for
this exact reason, the CIE defined the specific Delta E algorithms.
Later versions are also based on LCH values, so my intuition to use it
for distance was on a good start, yet these algorithms were refined a
few times to allow for corrections in perceptual uniformity
imperfections.
This was in particular needed to verify if a color is out of a CMYK
space gamut. The idea is to compare the distance of the RGB (or other)
and the CMYK version, since we cannot just check if the CMYK color is
out of the [0; 1] range (it never is). Instead if both colors are
perceptually identical, then we consider that the RGB color was inside
the CMYK space gamut.
The naive algorithm was giving any (or nearly) color as out-of-gamut.
Now using CIEDE2000, I get a much nicer results.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
Only the color dialog was getting simulation updates when the active
image changed, or when the simulation profile changed (while the active
image stayed the same). Now the Colors dockable also get updates.
Somehow, in some cases, the event box is not getting button events. I
had the case when creating new images (though it was working fine when
loading images!). I could not yet understand the issue looking at both
GIMP and GTK code and could not even reproduce by creating simple code
sample reproducing a similar pattern (an inactive button inside an event
box placed above the button and meant to catch click events).
This works as a workaround for the time being.
What this commit does is keep the same code logic while moving to
GeglColor. Yet it's not **really** space-invaded yet. What we need to do
now:
1. Take into account the image space, and this is what we must navigate
through, in particular for various representations of RGB or HSV.
I.e. that if the active image is in anyRGB, the RGB values shown must
be within anyRGB. Right now, everything is still shown/used as sRGB
(even though it's properly retrieved and transformed to the target
space thanks to GeglColor).
2. Show space info to make things clear and explicit, by adding some
label somewhere.
3. Allow to switch between image and softproof spaces, regarding
out-of-gamut display. I.e. that while RGB/HSV must be shown within
the image space (assuming it's anyRGB), we may want to show
out-of-gamut area (pink areas) within the softproof space. This may
mean adding a checkbox. Or maybe simply taking into account whether
we are in softproof mode or not?
4. We can likely move off gimp_widget_get_color_transform() into using
gimp_widget_get_render_space() for display drawing. We don't need any
soft-proofing or black point compensation for any of these widgets so
pure babl is fine. Indeed we want to show any in-gamut color
correctly (and not transformed according to specific intents or
through soft-proofing). We will take care of the proofing case with
out-of-gamut area showing only.
5. In the various drawing functions, we should move to
CAIRO_FORMAT_RGBA128F. The color selection area might be wide enough
that it makes sense to be more accurate, especially as we are
essentially showing color gradients in 1 or 2 directions in these
various widgets.
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).
Serializing palette colors is not possible right now as far too much
additional data are required, and anyway we likely wouldn't be able to
associate back the color to the right palette on deserialization,
removing any interest of keeping the index data anyway.
With that context in mind, let's just serialize palette data as basic
RGB within the palette's space.
- New libgimpcolor functions: gimp_color_parse_hex() and gimp_color_parse_name().
- GimpColorHexEntry is now space-invaded. Though recognized color names
and hexadecimal syntax are sRGB only (because CSS and SVG
specifications explicitly say that this syntax is for sRGB values), it
is possible to enter non-sRGB values with
gimp_color_hex_entry_set_color().
- GimpColorSelection is now space-invaded.
We historically have both the colormap and palette concept in core GIMP,
though they are actually kinda the same concept, except that with
"colormap" we work with an array of raw data and it's a lot less
color-aware. It is still much more efficient in some specific cases,
such as when converting the image (we can then convert the whole palette
as a single buffer, because the image palette is space-restricted
anyway), when storing undo data or when storing/loading in XCF.
But for all the rest, let's use gimp_image_get_colormap_palette() and
work with the GimpPalette API.
By default a palette can contain any mix of color models and space. These new
internal API add a concept of format/space restriction. For now this will only
be used for indexed images whose palette should only contain colors for the
specific palette format and space (at least as currently implemented in GIMP).
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.
The invasion extended to some core widgets too, in particular GimpColorPanel (a
subclass of GimpColorButton). There was quite a lot of code depending on these
widgets.
This includes improvements on the out-of-gamut colored corner being shown for
unbounded component types out of the [0; 1] range (with some small margin of
error to avoid e.g. a -0.0000001 value to show as out-of-gamut).
There are still improvements to be made on the color rendering. In particular,
it still draws as CAIRO_FORMAT_RGB24 cairo surface. We should probably move to
draw as CAIRO_FORMAT_RGBA128F eventually (more precision and even allowing to
draw unbounded colors with a possible option, instead of always clipping).
Also adding the libgimpwidgets API gimp_widget_get_render_space().
This one is kind of a huge deal, because the info returned by the color frame
was kind of messy (even though it improved lately, but space associated to color
data had to be kept in-sync by hand, which was bug-prone).
Now the color frame stores the data as a GeglColor, always aware of its space
and therefore able to do much nicer conversion. Also RGB and Grayscale options
now display the profile name of the color space (until now, we had only this for
the CMYK option using the proofing profile).
I still wish to get more options. Typically some people may want to get
RGB/Grayscale/CMYK values to other spaces (maybe sRGB, one of their favorite
profile as set in Preferences or just any random profile which they could load
from disk). Giving such ability to basically live-convert their pixel data to
various other color space would be very nice. We'll see if this will be
implemented for GIMP 3 or for after.
- New function gimp_cairo_set_source_color() which is meant to replace
gimp_cairo_set_source_rgb(a?)() eventually. This new function sets the Cairo
source color, using the target monitor's profile of the widget where the Cairo
surface is meant to be drawn on. It also uses the color management settings
(such as whether a custom profile was set, instead of using system profile, or
also simply whether color management was disabled at all). It doesn't
soft-proof the color yet.
- Padding and out-of-gamut colors drawing now use the new
gimp_cairo_set_source_color(). These don't need any soft-proofing anyway.
- Out-of-gamut color property in GimpColorConfig is now a GeglColor property.
We pass 2 GeglColor through the wire now. Since it is passed very early
(when sharing the configuration), I had some issues with initialization
order of GEGL, and in particular when calling gegl_init() before
gegl_config() inside _gimp_config(), I had a bunch of such criticals:
> Plugin script-fu: GLib-GObject: CRITICAL: Two different plugins tried to register 'GeglOpPlugIn-transform-core'
Anyway in the end, I store the passed colors as raw bytes and strings in
the GPConfig object, and re-construct the GeglColor last minute in
_gimp_config().
This fixes weird behavior when changing only the alpha value of a color, e.g. in
the channel color GUI. The before and after colors were considered the same. Now
they won't.
In particular, let's accept small margin of errors to determine that a value is
out of the [0; 1] range of its color space.
The specific use case is about a component at -0.000001 (or at 1.000001) which
will even just show as 0 (respectively 1) in the GUI and will be marked as
out-of-gamut. We want to avoid such thing to happen.
I also took the opportunity to get rid of a bit more GimpRGB code.
One of the big improvement in this commit is that text layers are now much
better at space accuracy. They were already space-aware, yet rendered as sRGB u8
only before being converted to the image's space. It means that text layers had
the following limitations:
* Any color out of sRGB gamut were trimmed.
* Precision was always 8-bit (even if the image was high-bit depth).
Now GimpTextLayout keeps track of its source space (for RGB and CMYK only, this
won't be as easy when we will support more backend, since Cairo has only RGB
support for image data) and the image TRC (in case it bypasses the color space's
TRB) and it draws within this gamut and space.
It means first that we are not limited to sRGB colors; we will draw text main
color in the full image gamut, with still 2 remaining limitations:
* Unbounded colors are impossible because Pango format (to color text) uses
hexadecimal (so even with half/float images, you can't draw out-of-gamut text
unfortunately).
* Main color precision is still 8-bit, yet a tiny bit better than before as we
at least follow TRC (so we avoid some of the precision loss when converting,
even though the bit-depth is still the biggest loss).
The outline color on the other hand is drawn through Cairo API entirely, in
float. This means that the outline color will now be without any precision loss.
Note that this depends on CAIRO_FORMAT_RGBA128F which is only available since
Cairo 1.17.2 which is not in Debian bookworm (our current baseline for GIMP
3.0). It means that the old precision will still happen with older Cairo
version, as determined by #if code at compilation.
I moved the function to select a valid contextual RGBA format as a core API
gimp_context_get_rgba_format(). This same API is now used in context actions, as
well as in the GimpDeviceStatus widget.
The latter now shows per-device fg/bg colors relatively to the active image's
format. The tooltip will also display contextual information (i.e. either the
image's name whose space is used, or sRGB).
Of course, this all updates when switching images by connecting to the
image-changed signal.
In space invasion world, we want color-related code to be contextual. When we
say "Increase/Decrease the red/green/blue channel by X%", it would actually mean
something different if you are working on a sRGB space or a wider gamut space.
Furthermore, it means also something different if you work on linear/perceptual,
overriding the space's actual TRC.
This is why this new code takes the active image into account and uses this as a
base for the space and TRC you are working on. In case you have no active image,
it defaults to the current GeglColor space (though really this case should not
matter too much). In case your image is not RGB to begin with, it uses sRGB
space.
Some old config files will contain (color-rgb) contents. Also some data, such as
historical tool presets (.gtp files) will have such values in their
(tool-options).
- 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.
Also the color is internally stored as GeglColor, though there are still get
APIs and signals using GimpRGB.
The equivalent PDB functions are also changed to use GeglColor, same as app/
functions.
… gimp_color_is_perceptually_identical().
gimp_color_is_perceptually_identical() is meant to replace gimp_rgb_distance()
which is anyway always used to decide whether 2 colors can be considered equal.
So rather than having a distance algorithm which we won't be able to change
later on (if people start relying on specific values), let's just give the
answer directly on what's a same color (perceptually) or not.
Also now the distance is computed through the intermediate color space LCh which
seems to be one of the most perceptually uniform space, therefore a good choice
for such an algorithm (comparing distances on a non-perceptual uniform space
doesn't make very much sense, since a same distance may be perceived differently
in different subspaces).
This is a first commit to really getting rid of GimpRGB within core and
PDB/plug-in code. This will make color conversion reliability a lot better as
GeglColor will handle conversions for us. The goal is that we should keep origin
color space (for instance when picking colors in a GimpPickable, or when storing
in the FG/BG colors or in paletters) until the last second and convert at use
only.
It's still very much work-in-progress.
These 2 functions were removed in commit 89c359ce. They were in fact used and
clearly this historical API seems interesting (though we can likely do the same
thing using the drawable GeglBuffer, but this way is much easier).
This is now reimplemented using GeglColor instead of raw data.
Eventually this is meant to fully replace GimpRGB (as well as GimpHSV, GimpHSL
and GimpCMYK), both in libgimp and in core code, as part of both the space
invasion and the API rework. For this first commit, I keep this new object side
by side to GimpRGB.
gimp_drawable_filter_apply () is affected
by the active selection. This causes display
glitches when merging all filters or
undoing a merge while an active selection
is on the image.
This patch saves the current selection,
clears it, merges/unmerges the filters,
then reapplies the selection to avoid the
problem. In the future, this should be
re-examined (when filter masks can be
edited).
Resolves #10802.
Since the GimpProcedureDialog port, the Windows version
of the Screenshot plug-in has been missing the
"Screenshot Delay" option. This is because Windows did not
have the SCREENSHOT_CAN_DELAY_WINDOW_SHOT enum
set. Adding that back in restores the option.
Here, the instructions was hard to find in the middle of maintainer stuff.
Also, be able to build GIMP without dev-oriented distros is something very
desirable, and the gimp-web-devel is the suited place fot it.
Resolves #10736.
By default, any filter added with a drawable with
gimp_drawable_filter_new () will be added on top
of the filter stack. Now that we have NDE effects,
there can be multiple live filters when drawing.
The Warp tool applies a GEGL operation as well,
and now it draws on top of any existing effect.
This patch adds code to move the Warp's filter
below any other NDE effects so it operates on
the raw pixels only.
Note that a longer term solution might be to have
a separate stack for tool-based GEGL operations,
but that would be a post 3.0 discussion.
- The icon itself was changed to a "search" icon. Though it kinda made sense to
keep the "link" reference when I first implemented this, as a reference to how
we used to link items (whereas now we select them together), in the grand
scheme of things, it's not such a good idea and many won't likely understand.
But everyone will understand a "search" button. :-)
- It's now next to the label displaying the number of selected items, in the
item tree view header. This makes much more sense there. Also it makes the
long list of bottom buttons slighly shorter.
- Finally I make this feature accessible to the channels and paths, by actually
moving it out of GimpLayerTreeView and into GimpItemTreeView.
Certain filters like Supernova have a
random seed property. According to the
specifications it's an unsigned int, so we
can save and load it with existing
functions.
Aaaargh! I think this was the main issue which would explain why the problem was
mostly happening on the packaging job. In this job, we were still consistently
calling `pacman --noconfirm -Suy` (i.e.g "Synchronizing package databases")
which we had stopped to do for the CI builds as that was highly increasing
chances of locking pacman's process.
This is the command suggest by MSYS2 developers here:
https://github.com/msys2/MSYS2-packages/issues/4340#issuecomment-1887695290
They also say to run it outside the MSYS2 environment, which is why it's in the
CI rules, not in the shell script.
Honestly at this point, it feels like we are just stacking weird workaround to
get it to fail not too often. ;-(
Fixing a case where the script continued after a failed `ninja`. After further
testing on how `set -e` works, it looks like a toplevel `false && true` command
will fail the script (which is what we want), but it won't when inside an `if`
block!
Breaking it down into 2 separate calls fail the script correctly though. So
let's do this.
MSYS2 pacman gets randomly stuck on Windows/Aarch64. The actual issue is still
being investigated by upstream projects, though anyway it's bad for us right
now, to the point that there are discussions to remove Aarch64 support from the
Windows installer (whereas it just got added recently!) in #10729.
This is an attempt to a workaround. Instead of getting stuck forever and waiting
until the whole job times out (per Gitlab CI settings), I time-out (after 3
minutes) the pacman command within our script and try again, up to 2 more times.
Hopefully one of the calls would succeed.
I also send a SIGKILL through the timeout (though I have no idea how signals
translate to Windows processes) and run again taskkill after this, which may
seem overkill. Interestingly I get output for both, which seems to indicate that
the kill succeeds in both cases (because of several processes?).
Anyway clearly it's a bit of random code not completely understood, but the
inability to test this all locally clearly doesn't help so it's good enough for
the time being.
See: https://github.com/msys2/MSYS2-packages/issues/4340
Resolves #10769.
Flattening an image or merging down layers caused
us to lose NDE filters on undo, as we flattened with
gimp_gegl_create_flatten_node () which didn't create
an Undo/Redo object.
To fix this, we merge the filters down beforehand with
our API so that they will be restored when undoing.
Resolves #10768.
During NDE development, the Show/Hide All
function name was changed. This was not fixed
in one location where we blocked it during popup
creation, so the signal was running on dead objects.
This patch fixes this. It also fixes a few formatting
errors made during NDE development.
Two shell commands got merged as one line. This seems to work fine on
hmartinez82's runner, unlike on our new runners. Anyway it is likely good
practice to clearly separate the commands.
Fixing:
$ if ($stuck -eq "True") { Remove-Item -Force -Path "C:\msys64\var\lib\pacman\db.lck" Write-Output "Cleaned previous stuck pacman" }
Remove-Item : A positional parameter cannot be found that accepts argument 'Write-Output'.
At line:279 char:26
+ ... q "True") { Remove-Item -Force -Path "C:\msys64\var\lib\pacman\db.lck ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Remove-Item], ParameterBindingException
+ FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.PowerShell.Commands.RemoveItemCommand
Resolves #10766.
Currently, GIMP does not support applying or editing
filters when the layer is pixel locked. This patch
prevents users from attempting to edit filters via the
NDE popover UI, and notifies them of why.
If any NDE filter is hidden when merged, the entire layer
is hidden. This patch changes the behavior so that the
invisible filter is removed instead of committed when
merged down.
Without this, when creating the new config folder for the first time
(update from 2.10 to 2.99/3.0), if say "Legacy" icon theme was set, it
would not show on the first run, though it would show on the second run.
Now it shows directly on the first run.
After ab626e79, Script-Fu v3 now has the
SF-OPTION parameter again. This patch
ports a few scripts that use it or were
not otherwise covered by other merge
requests.
Note that further improvements are
necessary to allow these to work on
multiple layers simultaneously.
For version 3 scripts, using script-fu-register-filter
Widgets for SF-OPTION and SF-DIRNAME
Fixes #9992
Test case is Sphere v3.
Note that SF-VECTORS is still not supported,
until there is a VectorsChooser widget in libgimp.
A step towards deprecating old-style scripts using script-fu-register,
and deleting script-fu-interface, the duplicate dialog for SF.
But we still need to change or replace script-fu-register (for non-filter plugins)
to use GimpProcedureDialog.
Some GIMP-custom GEGL operations do not use GimpConfig to
store their properties (for instance, Threshold).
Previously, we weren't copying over their values when editing an
NDE filter.
This patch adds code to copy over the Gegl properties if there is
not a GimpConfig object attached to the filter.
In particular in a cross-compilation environment where you don't have an exe
wrapper or cross-host run ability, you still want to be able to configure GIMP.
It is also possible to install lua scripts anyway with -Dlua=enabled, bypassing
ability to test lua-lgi presence (a warning will be outputted at configuration
time, but no error).
While this is the job of `set -e`, putting parts of the script in shell
functions hid error returns in the build-deps-msys2 script.
Cf. #10729.
For the build-gimp-crossroad script, let's just add `set -e`.
Cf. #10725.
I believe there is a real use case for darker or lighter themes, but this
particular theme is not particularly maintained and has no light variant (or to
be accurate: the light variant is just a link to the "Default" one). If someone
is interested in such themes, we'll welcome contributions to revive a new theme
which should have at the very least both a light and dark version, and we could
name it "Contrast" (rather than "Darker" which focuses on a dark variant only).
I think it's better to do it this way rather than releasing with a half-done
job.
The Compact theme code is nearly the same as the Default one, apart from setting
palette icon size to small (which is already something done by the "Override
icon sizes" setting in Preferences), setting font-size to small (which can be
independently set by our "Font Scaling" setting) and setting 3 paddings.
Rather than having this separate theme, it feels like just moving the padding
changes as part of the icon size makes sense. In particular since, when setting
icons to "Small" right now, the default padding really feels a bit huge and out
of place. So all-in-one seems a better choice.
At first, I wanted to set a padding proportional to the icon size, but it didn't
work well. For now, I'll just choose padding sizes manually.
If you run the GEGL Operation tool without choosing
a filter, it leaves a "gegl:nop" layer effect behind.
This is not useful, so we check and set such filters as
destructive to get rid of when applying an effect.
This was provoking a CRITICAL in #9712, in the GimpFgBgEditor which was tracking
the active image, but even before this, I experienced a crash in
GimpLayerTreeView code with the same steps.
The problem is that in some cases, the image switch happens once the currently
active image is already disposed. In particular we had the case in multi-window
mode where closing a window would free a GimpImage yet without necessarily
setting another image as active, since it depends on window focus in MWM (and
the other image windows may not gain focus immediately; this depends on the
window management logic).
Therefore we had various handlers in Gimp*TreeView (or GimpFgBgEditor and
possibly other places) code which tried to disconnect or work on now freed
pointers. To handle such case, let's connect to image finalization and set the
context to NULL image.
When working on #9712, I encountered this crash first before the main issue
(with the same reproduction steps as listed by Wormnest): reason may not be set
by the method. It's better to always explicitly set this variable to NULL first.
The current GTK algorithm for finding an icon seems to be:
main icon theme in choosen style > fallback icon theme in choosen style >
main icon theme in another style > fallback icon theme in another style
Where "style" is either color or symbolic variant of a given icon. The problem
is therefore if say your prefered style is "Symbolic" and you choose a
Color-only icon theme. In such a configuration, all icons which are also
available in the system theme with a symbolic variant will be used from the
system theme (even when they are actually available in the chosen icon theme
too, yet in a color variant) and you get a weird mix of part of the icons as
symbolic from system theme and another part as color from the chosen theme.
In order to avoid this weird situation, we only set -gtk-icon-style CSS value to
the prefer-symbolic-icons property if the chosen icon theme has both style
variants. Otherwise we force the only variant of the chosen icon theme.
The icon "gimp-wilber" is used to determine whether an icon theme has both
variants, which should be documented in the developer website for icon theme
makers.
The -Dlua option has 3 cases:
1. disabled: lua plug-ins aren't installed at all.
2. auto: lua plug-ins are only installed if we find a lua installation
with access to the 'lgi' module. We now do the actual test at configuration
(not only lua existence test, but also lua-lgi).
3. enabled: lua plug-ins are always installed but if no lua installation with
'lgi' module is found, a warning is displayed at end of configuration step.
Add tests of context stack ops.
Add test of paint methods.
Test convert to all precisions.
Test paint dynamics.
Test PDB as database.
Test PDBProcedure methods.
Test display methods.
Test drawable operations.
While the script is made aware of multiple selected layers,
it still only works on the top selected layer.
Mnemonics were also added to the GUI fields,
and an unused "type" parameter was removed.
The list contains, in addition to the GIMP deps, all babl and GEGL deps.
So, let's use it.
Also, nothing new under the sun. We already use a unique list on the
Windows build instruction page (for stable branch) and do the same to
Debian image job.
The merged icon theme is simply named "Default" and contains a color and
symbolic variant for all icons. While in 2.10, it made sense to have both icon
themes because a theme had no concept of a "symbolic" variant back then, icon
themes in 3.0 have this concept and we support this in GIMP through the "Use
symbolic icons if available" option in Preferences.
Until now, it was confusing to have both themes + this option, even more as you
could use the Color icons with the "Use symbolic icons" option, which meant that
if some icons were missing, you could end up with a mix of color and symbolic
icons (and oppositely using the Symbolic theme with the option unchecked).
The new state is much simpler and less confusing. Just 1 icon theme with both
color and symbolic variants (the latter being used by default).
Note that the identical meson.build in each size subfolder is still mandatory
because of the inability of meson (still!) to generate files with
custom_target() in a subfolder as output.
We were skipping tests when there is no display, which is always the
case on Windows. However, these tests always showed as succeeded.
Unless you looked at the test log, you wouldn't noticed that most of
the tests weren't actually performed.
Exit these tests with the value GIMP_EXIT_TEST_SKIPPED instead of
EXIT_SUCCESS.
You are not supposed to use g_assert in tests because g_assert can be
disabled using -DG_DISABLE_ASSERT, which makes tests fail.
Instead let's use the recommended replacement g_assert_true. At this
time we are not bothering using more specific g_assert_* functions,
since there are plans to change our test suite.
gimp_config_writer_printf () is used to print out a gsize variable, data_length.
gsize's actual size varies depending on platform, so using the format "%lu" throws
a warning on some platforms and switching to "%llu" throws a warning on others.
@Wormnest suggested ("%" G_GSIZE_FORMAT) as a universal format to resolve
this warning.
Until now, we were following a similar concept of color schemes as what most OS
are doing. For instance, Freedesktop recently introduced a tri-state color
scheme of "Prefer Light", "Prefer Dark" and "Default", the latter being either
whatever the software prefers (e.g. we prefer either Dark or Gray for graphics
software usually) or what the system prefers. See #8675.
Until now, with GTK, we only had a boolean "prefer dark" setting through the
"gtk-application-prefer-dark-theme" settings. There is not even a "prefer
light".
Nevertheless for graphics application, there is clearly a third case (fourth if
we added a "follow system color preferences" which we don't implement for now):
gray mode and in particular middle gray. Having a middle gray UI is often
considered a necessity when working on colors in order to protect our perception
of color from being influenced by surrounding UI.
To fill this need, we were proposing a Default vs. a Gray theme in GIMP, but
this was a bit confusing and felt illogical, as discussed on IRC some time ago.
Also depending on whether you chose "prefer dark" or not for the gray theme,
this one was itself 2 themes, which made things odd and harder to work on.
Instead this commit:
- adds a color scheme concept in GIMP with 3 variants so far: light, gray and
dark. A possible fourth (future) variant might be to follow the system
preference (do all OS provide such a queriable option?).
- Our Gray theme is merged into Default (as the gray color scheme variant).
- Custom themes can add the following CSS files: gimp-light.css, gimp-gray.css,
gimp-dark.css which are the base file for their respective scheme. gimp.css is
still used as a fallback though it is not necessary (our own Default theme
does not provide a gimp.css anymore). Custom themes don't have to provide all
3 variants. A theme can just provide one or 2 variants if it only wants to
support 1 or 2 use cases.
Chooser return GDK_EVENT_STOP so parent manager does not also popup second menu.
Specifically, return the result of the call to gimp_editor_popup_menu_at_pointer.
When a menu does pop up (for a dockable), that result is GDK_EVENT_STOP
and the event does not propagate to the parent widget.
Added a comment about why we ignore the result of a call
to gimp_editor_popup_menu_at_pointer in another place,
since it is not obvious why that call is different.
All other current behavior retained.
Other current behavior might be separate issue:
LMB or RMB outside any item, or in the current selected item,
in the chooser that popups from the toolbox,
should probably close the popup chooser, or give an audible alert,
because it does nothing.
Note that a chooser is also used in a remote dialog for a plugin,
and it closes a different way, choosing an OK button.
MINGW64
- uses 0x601 as value for _WIN32_WINNT. No need for us to define
it to that value or even lower values in some places.
This also gets rid of: warning: "_WIN32_WINNT" redefined
- has 0x0502 for WINVER, so get rid of us setting it to 0x0500 in
gimp-app-test-utils.h. It also seems that the need to use G_OS_WIN32
has disappeared here.
- DIRECTINPUT_VERSION is 0x0800, no need for us to set it to that value.
- AI_ADDRCONFIG was apparently missing from the MINGW headers in the
past, but not anymore.
The list of objects where the config object is a dedicated custom class (instead
of a runtime-registered class) is well known. These are the operations
registered inside gimp_operations_init().
The list inside gimp_gegl_procedure_execute_async() which the previous commit
was updating was not right: it was still missing "gimp:hue-saturation" and
"gimp:threshold" should not have been on the list (this was generating a
CRITICAL when trying to get the "config" property on this object).
Instead let's add some init/exit() functions in gimp-operation-config API to
distinguish the operations with custom config (registered during init) with all
the others. Then we add gimp_operation_config_is_custom() which can be used
everywhere where we want to verify if an operation is using a custom-made config
object or a generated class just mirroring the operation properties.
This way, we should not get out-of-sync anymore.
Adds gimp:color-balance to the list of
GIMP-specific GEGL operations we
retrieve the GimpConfig settings from.
Also prevents trying to set a GEGL
property when editing if it couldn't be
converted properly (e.g. GimpConfig)
Now that we save GEGL operation arguments ourselves (instead of relying on
GEGL-generated XML), we can serialize and deserialize GimpConfig arguments which
are used in various operations implemented within GIMP core code.
Additionally:
- Also support saving and loading all enum types.
- PROP_EFFECT_ARGUMENT renamed to PROP_FILTER_ARGUMENT for consistent naming.
- A bit more accurate handling on save and load errors with dedicated messages
to various issues.
- Use PROP_FLOAT_OPACITY instead of the obsolete 8-bit PROP_OPACITY (actually
32-bit but stored as 0-255 int).
- Fix a leaking string.
*It's possible to have one layer selected but edit the filter of another layer.
The FilterTool code was updated to use the filter's drawable if editing.
*Prevents editing if multiple layers are selected.
This is a current limitation of the filter tool itself, but it was causing issues with NDE.
*If an XCF with a filter from a third-party plug-in is loaded, the filter won't be
created if the user doesn't have it installed.
Note that GEGL still throws a lot of warnings about missing properties - not sure how to resolve that.
*Refresh drawable when finished editing a filter to fix issue with lingering preview splits
*Fix issue with loading more than one filter after XCF format changes
- Do not leak allocated return value of gegl_node_to_xml_full().
- When merging layer effects, use gimp_drawable_filter_commit(), making
sure we use the exact same code path as when applying layer effects
destructively from the start. This also ensures that filters are
properly removed from the filter stack (unlike
gimp_drawable_merge_filter()), which was the reason why the rendering
was wrong (hence getting the buffer without effects first, then
reapplying it after was only a workaround to an actual bug).
- When removing a filter, verify the object still exists before doing
anything with it. If this was the last reference, we don't want to
call functions on this object. In gimp_drawable_filter_commit(), we
set up a weak pointer. In gimp_drawable_filter_remove_filter() itself,
we save the pointer to the filter's drawable before actual removal (as
we don't want to dereference a freed object later on).
- export_merge_layer_effects() should merge filters recursively through
layer groups.
- clean up the XCF code:
* No need to wrap the effect pointers list into 2 zero offset. Only
have one zero offset to indicate the list end.
* Add the layer effect mask in the effect structure (not in the layer
structure), similar as for layer masks.
* Effect name and icon made as main data in the structure, not as
properties.
This patch implements an initial form of
non-destructive editing. Filters now stay active
instead of being immediately merged down.
A new column is added to the layer tree view, which
can be clicked to show a pop-over menu.
Filters can currently be hidden/shown, edited, reordered,
deleted, and merged down from this pop-over menu.
Currently, this works on layers and layer selections only.
Plenty of room for improvement!
Use g_signal_connect_object to ensure object passed to handler
is not destroyed in the middle of the handler by knock-on signal handling.
Note there are comments about this in gimpcontainertreeview.c line 1592.
And similar code i.e. calls to gimp_container_view_get_container
that seem to be intended to solve but might actually also be susceptible.
Those calls in icon view throw CRITICALs during this issue.
But testing of the tree view (a list instead of a grid)
doesn't seem to crash, so leave well enough alone.
As suggested by Jehan, the manifest will be configured by meson.
Of course, for CI compliance, this pushes the job to a further stage:
'packaging', which is what Flatpak is about, after all.
The distribution job name has also been changed, because when Store job
is merged, this will be the new nomenclature of the distribution jobs,
which was not changed since !1171 by lack of time.
Per @lukaso, the "rightwards triangle arrowhead" character
doesn't render on MacOS. This patch uses a different character
for MacOS only until a standard character can be decided on.
There is no point in keeping .patches in our source since we aren't applying
them and there are "backup" MRs in GTK: GNOME/gtk!3275 and GNOME/gtk!4432.
Resolves #10657.
d120e592 fixed a crash when pasting into an empty image.
However, it created a new issue when pasting into a layer mask.
It caused a later call to gimp_drawable_convert_type () to fail, as
the pasted image would not need to be converted if the image's
settings were used rather than the drawable.
This patch fixes both issues by checking if the selection/image is empty,
and assigned the base type and precision values from either the selection
or the image accordingly.
Resolves #10651
The "Remove All Guides" script calls
gimp-image-find-next-guide, which per
its description can take in 0. However,
the parameter sets 1 as the minimum
value.
This patch fixes the range so that it can
accept 0, which enables the Remove All
Guides script to work again.
It also updates the script to the new
multi-layer aware API.
- Drops HACKING file (it is outdated and we have the "same thing",
updated, in the devel site), but moved PDB content to the README
* Update various links now to the devel site
+ Added 'TODOs' to avoid confusion from titles with empty content
and removed some that are already implemented
Now, the script reads the major.minor version automatically from the main
meson.build file, reducing maintenance work, which is already especially
high regarding flatpak because of the natural hashes updates etc.
Also, a small organization made to make the code more humanly readable.
As consensus on Windows contributors, it is more useful for most users
the generation of the desktop shortcut by default.
Now, users who don't want it should uncheck the option in custom install
or manually delete the shortcut after a full install.
It was not possible anymore for a plug-in to add a menu item to the
local Layers, Classes and Paths dialogs using <Layers>, <Classes> and
<Vectors> at the start of the menu path.
For the first two this was due to an extra length parameter and the
drawables now being inside a GimpObjectArray. To fix that we check
inside the object array for the correct type names.
I'm not sure if Vectors ever worked, but testing shows it only adds
runmode and image parameters. To fix that we do the same as for
ColorMap.
The 'jhbuild' build of GIMP (Windows only) was added in 2013 and then maintained
by only one contributor (it even offered unnoficial nightly builds) until 2017,
when it never received a new jhbuild-specific commit again.
After so long, update it to keep up with current development status is quite hard,
so it is reasonable to remove this already dead version of GIMP.
Resolves #10643.
Prevent gimp_modifiers_editor_show_settings () from being called
when the user clicks the Modifier Reset button in Preferences if
there is no device connected to GIMP.
For certain small selections, the pattern preview can't be loaded.
Since e1e30c6f assumes the pattern loads, this could cause a
crash if a dialogue with the preview is visible.
This patch checks if the scaled pattern was loaded before using
it, and otherwise uses the default pattern.
* Fixes an ARM .patch that stop to working after !1171, causing job fail
* Changes the logic of system upgrade (pacman -Syyuu) to be less redundant
This also improves consistency with the Debian jobs
Fixes #10605.
Export to xmc when image width or height is 256 pixels
causes a crash. Add equality check to an assert to stop
the plug-in from crashing.
Resolves #10530.
In GTK2, setting a window's scrollbar policy to GTK_POLICY_NEVER
hid the scrollbars. In GTK3, this also makes the window automatically
resize to fit the contents. Since ImageMap displays the full drawable
with no scaling, this caused the plug-in window to be very large for large
layers.
GTK_POLICY_EXTERNAL in GTK3 works the same as the GTK2 version of
GTK_POLICY_NEVER, so using it instead fixes the problem.
The default width and height magic numbers were also replaced with
constants.
- file-psd, sig[4] and block_len variables are initialized to stop uninitialized warnings
- file-xpm, g_file_peek_path () is cast to (char *) to stop "discarded const" warnings
- gimpconfig-serialized.c, %llu is used instead of %lu to stop overflow warning
If a system theme sets the background-image property for stacks,
it recolors the main canvas when empty. It also adds a border to
the toolbox Wilber area.
Additionally, the Credits page of the GtkAboutDialog has odd colors
due to general viewport grid styles overriding the GTK default.
This patch fixes these problems, and adds a custom CSS class to
the GimpAboutDialog for current and future work.
The previous commit did not fully convert the title/status bar
format string to be UTF8-clean, due to a misunderstanding
of the logic behind the symbol used to indicate an image
was dirty.
Rather than always grabbing the 2nd character in the format
string, this patch now grabs the next character in the format
string after the %D, %N, %C, and %E commands.
During the API port, the Map Object
plugin had some parameters added and
others changed to GimpChoice strings.
This broke the Spinning Globe filter which
called on the map-object plugin.
This patch updates the procedure call and
fixes ranges in the map-object plugin so
spinning-globe works again,
but larger scope warnings persist.
No functional change.
I did this while chasing #10590 and #10591
The refactoring moves replicated code into functions.
So readers can understand better without having to compare sections
of replicated code.
The comments also highlight issue #10590.
Use g_connect_signal_swapped for "resource-set" signal from Resource Choosers,
to match the signal handler expecting "callback data" in the first arg.
Otherwise the first arg is the object emitting the signal.
Resolves #10611.
In GTK3, GtkRadioButtons are set using the "active" property
rather than selected, so the callback needed to check the
GTK_STATE_FLAG_ACTIVE flag instead of GTK_STATE_FLAG_SELECTED
when changing grid types.
The code was also reformatted to match current coding style.
- To set color values in the 0-255 range we now have to use set_uchar.
- Because setting a default color is not working, the color in config
could be None, which if the color wasn't changed caused a CRITICAL.
Let's check for None and if that is the case then manually set our
default color.
When cancelling foggify we get the following error:
AttributeError: 'GimpProcedureConfig-python-fu-foggify' object has no
attribute 'end_run'
The end_run function was removed a while ago, so just remove this line.
The grid state was not correctly updated when changed from within the
grid settings dialog.
Instead of using g_simple_action_set_enabled we need to use
g_simple_action_set_state, since we don't want to change whether the
action is enabled or disabled, but the checked/unchecked state.
The current code assumes that one letter is one byte long.
This caused issues when using non-ASCII UTF8 characters in
the title and statusbar format strings.
This patch replaces the loop logic with g_utf8_next_char () and g_utf8_get_char ()
to get the next letter no matter how many bytes it takes up.
As reported in issue 10604, if the Align Tool is set to align relative
to a reference object and 'use extents of layer contents' is enabled,
clicking on a path causes a CRITICAL.
This is due to gimp_pickable_auto_shrink () being called, when GimpVectors
are not GimpPickables. A datatype check is added before calling the function
to prevent the issue.
When opening images like DDS or EPS that have an options dialog,
we either get a crash, or criticals.
The critical made clear that there is a problem dereferencing:
(gimp-2.99.exe:9900): GLib-CRITICAL **: 14:52:58.831:
g_atomic_ref_count_dec: assertion 'old_value > 0' failed
Looking at gimp_file_dialog_progress_get_window_id we see that the
handle doesn't get an extra reference, while in other similar places
the handle is duplicated.
Using g_bytes_ref on the handle fixes the criticals for me.
Due to GObject Introspection we can't have the last part of an
identifier start with a digit, since that part will be used in Python
as the identifier, and Python doesn't allow that to start with a digit.
e.g. GIMP_ROTATE_90 would be used in Python as
image.rotate(Gimp.RotationType.90)
To fix this we add DEGREES in front of the number, without a '_',
even though that looks ugly.
With the sample image that contains the XMP namespace Item with the
correct url included, it is not returning the url when we ask for it.
This seems to be an exiv2 issue, but needs more research.
What GIMP doesn't do, is report that the namespace url we were looking
for wasn't found, and make sure that this doesn't block us from
handling all XMP tags.
To improve this on our end, we check if there was an error getting the
url, and if yes:
- We generate a warning message
- We create a dummy namespace url, with a special check for the missing
Item namespace to give it the correct known namespace url.
Previously, the console's font color was hardcoded to #006000.
This did not stand out well on darker theme.
This patch pulls the widget's foreground color from GtkStyleContext
to ensure it contrasts sufficiently with the console background color.
- Fix "no icons" errors generating loaders.cache with .cmd (CI-Cross).
! This is a sub-optimal fix, but it's better than a useless build.
- Fix "no interpreter" errors generating .interp with Meson (CI-Native)
and generating .interp and copying .typelib with .cmd (Local-Native).
! This is a sub-optimal fix to Local-Native, but plug-ins will work.
- Fix "no iso" error copying iso_639.xml with Meson (Local-Native).
The Inno installer scripts contents (only 3 files: files, gimp3264 and
32on64) and filenames have been organized, making them much easier to
read, and slightly less hardcoded so less prone to being misunderstood
and pervasively receiving packaging stuff.
Just to be clear, one more time: the Inno installer (or future MSIX)
scripts never should be the center of attention. This "installcentrism"
caused a domino effect of partially "abandoning" the packaging, build.sh
and the meson scripts, which explains the existence of this MR...
(Some things still hardcoded since wildcards in Inno are very limited.
Also, the rational ordering principles of this MR were not applied since
these scripts are heavily based on the x86 .zip package and changing the
order of things here, according to my tests, breaks things quite easily)
The CI crossbuild job now use the same main script (and the same
sub-scripts of linking and debug generation) of the native CI for
packaging. These unified scripts greatly facilitates maintenance.
The crossbuild deps script is now more consistent in relation to the
native one. As this is polished, the cross one is now polished too.
A crossroad gimp build script was created with a more clear code.
Also, finally make the script for packaging only, removing build step
stuff that shoudn't be here (glib-schemas generation) since this causes
disparity with the Local native build; and adding some packaging
decisions that shoudn't be in the installer scripts (eg. specific
folders of ghostscript, glib; no share/themes), which also facillitates
INNO (and future MSIX) maintenance.
The local builds now can use the same script of CI for sake of time.
The compatibility layer is very simple and makes the script more
used/tested, therefore more reliable.
The local builds now can use the same script of CI for sake of time.
The compatibility layer is very simple and makes the script more
used/tested, therefore more reliable.
Also, remove some redundacy on the code for better maintenance.
Now, we have only ONE list applicable for build-deps-crossroad.sh,
build-gimp-msys2.sh and package-gimp-msys2.sh, instead of hardcoding
3 times. This unified list greatly facilitates maintenance.
Debian changes:
- Since autotools has gone, we don't need to specify 'meson' in the
debian job and others.
- The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and
the meson sintax of Debian jobs was also updated.
Windows changes:
- Then, clarify that the win64-nightly and win32-nightly jobs are, in
fact, in the 'packaging' step, since we don't really "distribute" GIMP
in .zip and the commands are almost the same of the packaging .SH
script, without scripted optimizations for Inno Installer (or future
.MSIX), crucial for distribution.
- We don't need to specify "native" sufix in any build since they are
the rule and cross builds are the exception.
General changes:
- The job names was changed to be more consistent and in accordance
with the folders present in the artifacts.
- The 'nightly' sufix was removed from the Inno Windows Installer job
and others, since this doesn't reflect the real build frequency.
- The scripts filenames are altered to stay "in order". This is not
essential but ultra convenient since it is easy to view and search.
(The -uni suffix is explained in a further commit)
- All artifacts names now have the commit to avoid apparently duplicate
files when downloading same step artifacts from different projects.
- Finally, rearrange the order of jobs rationally: first the OSes and
archs (from the most free and modern to the most closed and legacy),
then the stages (from 'prepare' to 'analysis'), ending with the
frequency of jobs (from the most frequent, called at each push, to
the least/weekly).
Overall, this changes, although difficult to review at the first
sight, will avoid in the future quite "dumb" issues like:
GNOME/gimp#10195
When cutting and pasting a single layer,
drawables->data might be empty. This results in a
crash on Windows and a failure to paste on Linux.
Since this function is inside an IF statement that already
confirms it has a valid image, the base type and
precision are retrieved from there instead.
Resolves #10537.
During the port, the "green_invert" variable
was repeated twice rather than using the
"blue_invert" variable. This prevented the
fractal from updating when blue was changed.
This is intended to prevent system theme background-images
and borders from overriding those set by GIMP.
The minimum size of tabs is also explicitly defined.
Our handling of Photoshop's Blend Clipped Layers as Group is flawed
causing the order of layers to be messed up which may cause certain
parts of the image to become invisible or having the wrong colors.
This only fixes the incorrect layer ordering. Correct handling of
group layers with clipping needs a more extensive rewrite.
This is a manual revert of eac1df4b61
since other changes were made to the same lines.
Although using legacy layer modes for several blend modes improves
compatibility with Photoshop, we found out during testing of the
image from issue #10498, that it negatively impacts loading of PSD's
that use Blend Clipped Layers as Group.
We convert this specific PSD setting by adding a layer group and
setting Composite Mode to Blend to Background.
However, our legacy layer modes do not support Composite Mode, meaning
that PSD's using this can show up using smeared colors.
Since this hasn't been in a release yet, let's revert this and rethink
how we want to handle the combination of these PSD settings.
Resolves #9933.
We used png_get_valid (pp, info, PNG_INFO_tRNS) to check if
an indexed PNG had transparency when exporting.
However, this function does not return TRUE/FALSE but instead
the contents of that PNG chunk. Since we use index 0 for transparency,
this function always returns 0. The non-transparent indexed export code
ran regardless, creating incorrect PNGs.
We set pngg.has_trns earlier if the image has transparency, so it's safer
to use this variable instead.
Magic number 1 changed to 2 in one place. Missed in earlier fix for #10127.
Changed magic number to a defined macro constant so it might not happen again,
should GimpConfig change again.
Substantive change is call gimp_item_get_by_id instead of gimp_drawable...
And a few type changes from GimpDrawable* to GObject*.
Lots of renaming of functions, substituting "item" for "drawable."
Update comments.
Made one function static that was already private.
Fix the test case gimp_vectors_set_selected
Add more tests
Enhance testing framework, add function assert-PDB-true
Enhance some tests: make test files order independent
Fix tests broken by recent changes to GIMP
There was the question on whether it needed an hyphen or not. The hyphen
naming was often used to describe the "Hard-edge painting" style, though
even for this, it was not an absolute case. Depending on English writing
style, we could also find "hard edge painting". Also Liam was noting
that when the term appears by itself, as a noun (rather than a
qualificative), it was likely best without hyphen. So we went for the
no-hyphen wording.
Then there was the capitalization question: should capitalization rules
of data labels apply to parts between parentheses? I went with the
answer that *yes*, since it's part of the title anyway. And without the
part between parentheses, we'd have several data named the same. So it's
just as important.
As a consequence, I also re-capitalized "FG to BG (HSV
Counter-Clockwise)" and "FG to BG (HSV Clockwise Hue)" gradients,
following this updated rule.
Resolves #10477.
The dark theme box-shadow for buttons does not blend well
when hovering over it, compared to the light & gray themes.
This patch adds an additional CSS rule to make the box-shadow
no longer clash in dark theme.
Some 2.10 modes, even in perceptual space, don't produce the same
result as PS. Now, the mapping table takes this into account, which
avoids surprises for the user.
The mapping table was generically indicating 2.10 modes as first choice,
which was resulting in terrible PSD compatibility in some cases. This
commit fixes this using legacy modes verified with latest PS version
(see attached files in MR).
Comprehensive rewrite of the DDS import routine, in the interest of
easier maintainability and readability. Adds formats.c/h, containing
tables and functions related to reading and parsing uncompressed files.
Importer now supports nearly all non-video uncompressed formats.
Includes a variety of minor-to-moderate fixes made along the way
which could not be pulled out into separate commits due to dependence
on other aspects of the rewrite.
Resolves #10454.
When porting to GimpProcedureConfig, all
light types were set to "Point" when 2 - 6
should have been "None" by default.
This patch fixes the defaults.
1. Recent changes to arg validation reveal bug in call to gimp-drawable-edit-gradient-fill,
supersampling arg must be >0
2. Make easier for testers to invoke by reducing the declared drawable capability
to SF-ONE-OR-MORE-DRAWABLE
Now use gimp-resource-delete
Drive-by fix of bad call to gimp-context-set-pattern.
Fixes other calls to gimp-font-delete, etc. in a test script.
Partly fixes 9867.
Due to a bug in commit de5c805cbb, which
changed the choice widget between line and paint tool to a
GtkStackSwitcher, changing that choice did not work anymore.
The reason being that the stroke method wasn't being updated on clicking
stroke. We fix this by setting the stroke method when OK is clicked.
When creating the dialog we also set the stroke method, to reflect the
last used choice, since that was also missing.
See discussion in !946: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/946#note_1768869
On Windows/macOS, the pad device is probably not even showing at all
right now, though I can't test. Also it could be eventually implemented
with pad actions support (see Luca Bacci comment in the same MR) using
WM_POINTER API on Windows.
On X11 though, the pad device is shown, except it is kind of pointless.
So I am disabling the frame (making it insensitive) and add a tooltip.
Handle some statefulness in actions taking a double parameter, in order
to make them friendly to GtkPadController and its pad ring/strip
integration.
The GtkPadController emits those actions with a double parameter
expressing the absolute value (e.g. 0-360 for rings, 0-1 for strips),
take care of converting these absolute values to relative changes
that increase/decrease the current GimpDoubleAction value.
Going for relative increments/decrements increases the genericity
of rings when mapped to actions, as going with the given absolute
values would mean means rings could be mainly mapped to angle-like
actions, reducing its usefulness.
We have everything in place to create GtkPadControllers converting
events into actions as configured in settings, and the signaling
to trigger the (re)generation of those as device, window or configuration
changes appear.
Only the last bit attaching those controllers to actually handle
input was missing, now done in this commit.
Since there may be multiple configured tablets and pads, we need to
keep track of per-device controllers to handle the configuration for
those. This mapping is kept in GimpImageWindow as the "main" toplevel
(i.e. the one(s) typically considered "keyboard focus" and receiving pad
events) and ensured to be kept up-to-date through the ::configure-pad
signal.
This API call will snapshot the current configuration of a device
into a GtkPadController, that is created and attached to a toplevel
(this event controller only acts on toplevels).
This controller will handle pad events, trigger actions, and update
compositor feedback (e.g. GNOME Shell pad OSD) as per the actions
mapped in the configuration dialog.
If a pad device configuration gets changed, or reset, we should trigger
the creation of new pad controllers for the existing toplevels.
Add the plumbing so that saving/resetting a device configuration will
result in the same ::configure-pad signal, and trigger it from the
relevant places.
In order to apply the pad configuration so it does something, we
need to create GtkPadController objects on each toplevel for each
configured pad device.
This signal will work as a hint that a new GtkPadController should
be generated for the given device and current configuration. At
the moment, emit it when pad devices are added or removed.
The UI is heavily inspired in the existing one for midi devices
and the such, as the restrictions are somewhat similar. Since there
is not enough information to introspect the device without the help
of libwacom (and the UI should work with tablets unsupported by
it, regardless) the list starts empty, and there exists a "grab
event" button to press pad buttons (or use rings/strips) and
create/focus a list item for the button/mode.
Double clicking on an action (or pressing the "edit" button) spawns
a different dialog with a GimpActionEditor to select an action.
And lastly, actions can be deleted with the "delete" button.
Pads may have different modes (e.g. leds in the tablet) that apply
to all pad features, the list will allow different actions to be
set on the same button in different modes. This basically multiplies
the amount of mappable actions by the number of available modes.
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.
Fixing:
> Scalar value @inargs[...] better written as $inargs[...] at pdb/lib.pl line 247.
> Scalar value @outargs[...] better written as $outargs[...] at pdb/lib.pl line 386.
This continues the theme definition work from bd398d5c.
A new edge-border-color tag was created
to allow for defined widget edges in both
light and dark themes.
The box-shadow highlights for buttons
and header/menubars was defined to
reduce system theme leaks. Some CSS
attributes were rearranges as well.
Per the official format specification and hardware implementation,
BC1 cutout pixels are always black with 0 alpha, whereas previous
versions of the plugin interpreted them as white. Commit f97e718e
partially fixed this, but made the behavior an import option that
also ignored the alpha component. This commit reverts the addition
of this option in favor of consistently following the spec.
The export properties "save-type" and "mipmaps" were left as ints
in Commit 427130be due to uncertainty on whether options could be
conditionally disabled on GimpChoice properties. From testing it
this functionality appears to work fine and is used in other plugins.
Now all combo props are GimpChoices and fully configurable from dds.c
Moves most of the code relating to YCoCg and Alpha Exponent into
misc.c/h, in the interest of making the rest of the codebase cleaner.
Removes the decode option from the import menu, as encoded files are
always decoded now (there used to be a menu button for doing this
after import, but with it gone there's no reason ever to not decode).
Finally, the remaining functions in color.c were only ever called once,
so these were extracted and inlined, and the empty file deleted.
Partial refactor of parts of ddsread to better handle DX10+ files.
Though not included here, this is necessary to import formats that
have no DX9 equivalent, namely BC6H and BC7, as the current handling
simply downgrades DX10 files and imports them like DX9 ones.
Extensive formatting and cleanup in the read-write files, and addition
of some comments where they seemed appropriate. Renamed a couple of
single-letter variables to be more descriptive.
Also removed an unnecessary global variable in ddswrite.c, and made
the "config" variable in ddsread a GimpProcedureConfig type, as was
previously done for ddswrite.
Fixes two major issues with mipmap generation, namely sRGB transforms
being applied both backwards and in 8-bit precision, causing severe
color degradation. sRGB transforms are now handled correctly and all
mipmap generation is done at 32-bit floating-point precision.
A new cubic filter has also been added (Catmull-Rom) which rounds-out
the existing lineup of cubic filters.
Also includes extensive code cleanup (sorry I couldn't separate this)
to mipmap.c/h and color.c/h
Recently some extra input validation was added, which caused the
gimp-image-set-selected-layers command in script-fu to fail with an
invalid value for argument 2.
This is caused by the object array contents always being set as
GIMP_TYPE_DRAWABLE, while the actual type may be a layer, etc.
So, let's set the actual type of drawable being used here by using
G_OBJECT_TYPE on the first data element.
Adds specific definitions for some widget borders that
are currently only defined by the system. This avoids
clashing colors depending on the system theme.
Resolves #10033
Not all system themes set a GtkRadioButton border-radius, so it
can default to 0. This creates a "box" around the radio button.
This patch defines the border-radius at 100% to make it universal.
These were using gimp_procedure_new, which was causing warnings like
LibGimpConfig-WARNING **: 13:56:33.270: couldn't serialize property
GimpProcedureConfig-plug-in-metadata-editor::image of type GimpImage,
and
gimp_plug_in_destroy_proxies: ERROR: GimpImage proxy with ID 1 was
refed by plug-in, it MUST NOT do that!
This also saves us from having to define image and run-mode parameters
ourselves.
We remove two warnings:
1. warning: format '%ld' expects argument of type 'long int', but
argument 5 has type 'GType' {aka 'long long unsigned int'}
Since GType is gsize, and this is not used in translations, use format
specifier G_GSIZE_FORMAT.
2. warning: enumeration value 'SF_IMAGE' not handled in switch (and more
similar ones).
Add a default block to let the compiler know we handle all values.
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.
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.
When auto expanding layers, there is an option that allows user to fill
the newly expanded part with the pattern. But without this change, it
was not possible to change the active pattern without switching to some
other tool like bucket fill tool. This commit allows that.
Also added option in Edit->Preferences->"Tool Options"->"Paint Options
Shared Between Tools" that decides weather the options should be shared
between different tools.
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.
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.
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.
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).
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.
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.
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.
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.
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.
Made `gimp_image_editor_image_flush` and
`gimp_image_editor_image_flush_idle` functions idle. For expanding
layers dynamically, we need to use gimp_image_flush funtion from the
paint therad. The gimp_image_flush eventually calls these functions.
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.
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).
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.
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.
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.
Currently we only use and retain "critical" PNG chunks,
discarding any safe-to-copy but non-image chunks.
This adds code to store them as parasites and then
include them on export, thus preventing loss of data.
when loading a BMP image with an invalid compression value.
The invalid compression check was missing a goto out (error exit)
causing the GError to be overwritten, which caused a GLib warning.
We add the missing goto statement here.
Overwriting a GIF animation results in loss of frames if a previous export turned off
animations.
This sets a parasite on import which we check for on overwrite. If it was an
animation originally, we overwrite as an animation as well.
Though we mostly removed floating layers/masks (formerly floating
selections) in many interactions, at least for default behaviors for
basic pastes, there are still advanced usage attached to this concept
and some advanced users are willing to have easier access to such items.
For this reason, this commit:
- adds edit-paste-float and edit-paste-float-in-place for pasting the
contents of the clipboard as floating data with default positionning
algorithm or in-place respectively;
- renames select-float to select-cut-float which does a cut and paste as
float in one action;
- adds select-copy-float which does a copy and paste as float in one
action;
- reorganize a bit the `Edit > Paste as` submenu with sections for the
floating data variants;
- add a "Float" submenu in "Select" root menu, containing the 2 variant
actions select-cut-float and select-copy-float.
This adds an import option for DDS DXT1/BC1 images to always use
transparency. This is the default behavior, since this was what always
happened until now and it seems that DDPF_ALPHAPIXELS is very rarely
set for these type of images.
However, as the mentioned issues explains, advanced compression
algorithms can use this transparency data instead to mean a black
pixel. There is however, no certain way to determine this.
For that reason, we add an option here, that, if disabled, will
interpret fully transparent values as a black pixel.
Some games apparently need dds images to be vertically flipped.
We already have an option to flip dds images on export, so it makes
sense to also allow flipping on import.
The anchor and merge down buttons are visible at the same time, which should not be the case.
Their visibility is now dependent on the existance of a floating selection.
The New Group and Search/Link buttons are also disabled when there's a floating section.
In addition to the requested DXGI variants we also load the older
D3DF versions, including handling of the signed versions.
We also set signed when the pixelformat flag DDPF_BUMPDUDV (added in
the previous commit) is set.
As shown in issue 10287, the system theme can create a
large white border around GimpSpinButton.
This patch fixes this, and also improves the border appearance
by assigning it to the background color rather than system default.
This adds support for loading RGBA DDS images with 16- and 32-bit per
channel. Loading is supported for 16-bit half float, 32-bit float,
16 and 32-bit unsigned and signed int.
This supports both the DX10 formats and the D3D FOURCC versions.
16- and 32-bit per channel images with less than 4 channels are not
yet supported.
When saving a PDF, you have the option to export layers as pages.
This works for a single layer group that contains multiple layers.
However, the option is disabled because the plug-in only checks
"top level" layers.
This patch adds code to check if the single layer is a layer group,
then enables the option if there are more than one layer in that group.
This completes commit 685c8bde99 where the http:// scheme was automatically
transformed into https:// in some cases, in particular while typing (when
pasting for instance, it was still possible to add an http URL). So let's block
"toggled" signal handlers when the URL is explicitely edited to prevent this
annoying issue.
(cherry picked from commit b991f8b361)
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.
While exiv2/gexiv2 could be able to load metadata from JXL files
directly, success is not guaranteed (depends on version and
configuration, for example support could be disabled or compressed
metadata could not work).
Loading metadata via libjxl should work all the time.
It is also important not to display dialog to rotate the image
according the orientation from EXIF, because in case of JXL,
the orientation is stored in codestream and it has priority.
This fixes this warning (as appeared with commit ad8b47bff7):
[1/235] Compiling C object libgimpwidgets/libgimpwidgets-3.0.so.0.9900.17.p/gimpdialog.c.o
../../../../../../../dev/src/gimp/libgimpwidgets/gimpdialog.c:774:1: warning: ‘gimp_dialog_set_title_bar_theme’ defined but not used [-Wunused-function]
774 | gimp_dialog_set_title_bar_theme (GtkWidget *dialog)
We could either put the whole `gimp_dialog_set_title_bar_theme()` declaration,
definition and usage into #ifdef, or only the implementation (making the
function a no-op on non-Windows platforms). I chose the former. There was some
discussion that maybe some implementation may happen later for other platforms,
but until then, no need to call it needlessly (even more as we don't know when
any theoretical other implementation would happen).
Certain dds images can have non-zero unexpected pitch_or_linsize values.
Until now we were only computing this ourselves in case it was zero.
Let's just always compute it and print an error to the terminal if it
differs from the value in the file.
A sample can be found in Galactic Civilizations 3: Bokeh_Hex.dds.
This change also allows us to safely load the poc in security issue
ZDI-CAN-22093 as that issue was apparently only caused by an invalid
value of pitch_or_linsize.
Optimize dds loading a bit by moving code that doesn't change outside
the loop:
1. The number of bits to be shifted when the source isn't exactly 8 or
16 bits depends on bytes per sample and isn't changing inside the loop.
2. Use rowstride variable to compute width * d->bpp once.
3. The check for rowstride > hdr->pitch_or_linsize doesn't change
inside the loop so move it out.
Inside the loop we only check the DDSD_PITCH flag once and move both
the size check and the fread check inside it.
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.
There were 2 issues here:
1. When more than 8 bits per sample are used, a previous commit changed
it so that we would be using 16-bit integer mode instead of 8-bit.
However, the actual code for this specific format was not updated to
reflect that.
We fix this by computing 16-bits per channel values and upshifting the
10 and 2-bit samples to 16 bit per channel.
2. The computation of masks was incorrect. It computed each channel
mask separately, based on whether it was <= 8 or not.
However, if any channel needs more than 8 bits, all masks should be
computed 16 bits since we will then 16-bit integer mode.
We fix this by checking all channel bits together, and if any is higher
than 8, but not more than 16, we use 16-bit masks.
I also took this opportunity to add support for 32-bit masks if we
ever need those.
@Wormnest noted remaining regressions after 8faad92e.
The second fread() only runs if the DDSD_PITCH flag is set,
so the error handling check should also be conditional.
Additionally, the ZDI-CAN-22093 exploit no longer runs but
still could cause a plug-in crash. This patch adds an additional
check to ensure the buffer size was within bounds.
@Wormnest pointed out that compressed files are likely smaller than
width * height * bps, so our check to prevent ZDI-CAN-22093
also caught valid files.
The size check is removed from load_image () and moved to load_layer ()
before the two fread() functions, as we know exactly how much we'll
try to read at that point.
When loading an xcf file, if a a font has already
been used, its file's hash is compared against the hashes
from the xcf file (to speedup loading), but if the font is from a .ttc file (a font
collection), then all fonts from that file will have the same file
hash, so the wrong font might be selected. a simple solution is to not
use the hash except as a last resort if every other field is identical.
These are not usable by plug-ins anymore which should store their data between
runs as arguments or aux arguments (in case of values which should be stored
from one run to another but are not really usable for non-interactive scripts).
These are per-plug-in (not polluting the whole process space with just random
strings as identifiers which could be used by other plug-ins) and even survive
restarts of GIMP.
I still keep these functions, but only internally, as they are used to store
settings of GimpAspectPreview, GimpDrawablePreview and GimpZoomPreview across
plug-in runs. Still I changed their API to set and return a GBytes directly
(mimicking the private PDB functions' API).
Also I remove gimp_pdb_get_data_size() which is useless when exchanging GBytes
directly.
Note that the 2 functions are still exported in the library, and only not
advertized through headers (so they are not really internal, just hidden), on
purpose, because we need to call them in libgimpui. So it is still relatively
easy for a plug-in to use them. Nevertheless I made clear in the function
documentation that these must not be considered public and could end up deleted
at any time. Any plug-in still trying to call these takes the risk of having
their code relying on unreliable API.
...by adding parameters and porting to
GimpProcedureConfig/GimpProcedureDialog.
Code was also rearranged to match the ordering
of other plug-ins.
As a note, the help message is "Special effects that nobody understands".
It would be nice if someone with more familiarity with this plug-in could
update the help messages to explain the parameters.
I had the case when "Sphere" script crashed, bringing down the whole script-fu
plug-in (while trying to reproduce #10214). Then after being run, we get a
dangling pointer to a finalized action object.
Even in successful use cases, we will want to give the ability to unregister
normal plug-ins/procedures wrapped as GIMP extensions, and there is also the use
case of temporary procedures, so I'm sure this bug could be reproducible even in
normal non-problematic runs.
I am pretty sure that this should be in single selection mode because we don't
even really have code to handle cases with multiple brushes or font selected.
Right now, we assume in many places that there is only one font or brush (or
other data) active at a given time.
Yet this code (or older versions of it) is old apparently and I realize that
even in 2.10, I can ctrl/shift click to select several data objects. This is the
weird part.
Anyway let's put this in single selection mode and see how it goes. If there
were actually use cases which I didn't know about, I'm sure we'll soon have
reports.
I could still see annoying scrolling up/down happening when we are deselecting
an item (typically with ctrl-click). In such a case, the cursor is on a
deselected item. Just make it bump to a closest item, preferably a visible one.
Note that "save-type" and "mipmaps" were left as ints rather than GimpChoice,
as some options are conditionally disabled and I don't know if that
is available in GimpChoice just yet.
A DDS loading bug related to 6ad54ca3 was also resolved.
The correct header value to check for the pixel size was not "depth" but "bpp".
My first versions were commits 98f0c448 then 1d8782915e but the more I go, the
better I understand the implications of the selection vs. the cursor. In
particular, when setting a cursor, which also initializes the selection to this
item only, the tree view would also scroll to this item. The current
implementation, which sets the top item as cursor, is therefore particularly bad
for multi-selection which doesn't fit fully in the view, because we also end up
scrolling up. Say you have a long list of layers, you first select the top
layer, then scroll down to the bottom layer and ctrl-click it: the selection
(now 2 items) works but you end up scrolled back all the way up.
This alternate version is much better, by ensuring that your cursor is at least
within the selection (hence avoiding the discrepancy between keyboard navigation
and pointer navigation, and which was fixed with commit 98f0c448), so that we
don't try to change the cursor when possible.
This was broken in commit 3e101922. Setting a cursor basically resets to a
single selection, invalidating pointer-made multi-selection.
But then we got back the bug it fixes, which is that we must grab focus after
the selection is actually made. So we now grab at the end.
This also had a bad consequence for multi-selection (again): if the focus was
not already on the tree view, gimp_container_tree_view_selection_changed() was
not called. This function was where the actual selection-changing is meant to
happen. So we had to shift-click (or ctrl-click) twice. The first time, nothing
would happen (but focus was given to the tree view). The second time, we could
finally update the selection.
This is why we add 2 different cases of focus grab, which should hopefully
handle all cases correctly, though this code is really extra-complex. This
replaces MR !1128.
I also remove (without replacement) 2 usages of gimp_get_data() without
associated gimp_set_data(). According to the comment, it looks like the
associated data was likely set by the GAP plug-in instead. Let's drop this.
Finally I see a lot of arguments, several of them being float arrays, so I
wondered if they were related to the curve and point arrays we are storing as
aux arg now. Apparently these arguments are not even used in the plug-in, right
now, which is explained in commit e318651c99. Maybe if these were actually
used/set and if we implement float array (de)serialization, would this aux
argument become useless?
Lastly, I deleted some code paths which were never used. For instance, stored
bval.total_steps was never set to anything else than 0 anywhere (so I removed
both the variable and the other code-path, which actually ended up being the
GAP-related data get). Additionally in p_bender_calculate_iter_curve(), there
was a big else block which was only happening when the GAP-related variables
were set. It got deleted too (as is a function only used in this block of code).
The argument is the serialized description of the generated fractal. Actually it
may even be useful as a non-aux argument. A GFile argument could eventually be
interesting too, though one arg per setting would be better of course (it allows
more easily to generate animated frames for instance). In such a case, the GFile
would be used in priority, otherwise the other args.
Notes:
* I didn't port to GimpProcedureDialog though it looks like it would not be too
hard (most of the GUI would still be custom GTK code, yet we could have the
generic "reset to initial|factory values" buttons and load/save).
* The custom "Reset" button (identical to what "reset to factory values" would
do) works fine anyway.
* The "run with last vals" works fine where there were indeed previous runs
(which may be in previous sessions), but crashes when it's actually the first
run ever. Some of the base structure data were not initialized. It should not
be too hard yet would require a bit of code reorganization to fix this.
- Argument "parameter-uri" becomes "parameter-file" (GFile instead of URI
string).
- Adding a "settings-data" auxiliary bytes argument to handle all settings for
the time being, instead of using gimp_get_data() and gimp_set_data().
- "last_file_name" was also removed from the ValueType struct, using the
"settings-data" arg instead.
- Fixing the non-interactive usage which was missing a gegl_init() call.
- Use GIO for various reading and writing to a CML parameter file.
- Better bubbling up of error messages.
- Fix the loading of the last section of CML parameters file.
- Also fixing deactived file dialog when clicking the open button a second time.
We use a GBytes auxiliary argument (i.e. not visible in the public API) which
perfectly replace gimp_[gs]et_data() API, in even better (since it also works
across sessions).
The "Reset to initial values|factory defaults" still don't work. We could make
these work even with the AUX args, but I feel like this would be far too much
work for a non-optimal solution anyway. The real solution can be when we get
more public arguments to this PDB procedure to handle every setting
individually. This can happen after GIMP 3 release (especially now that
arguments number and order don't break the PDB API anymore).
I added a bunch of arguments, in particular nearly all the settings in the main
dialog, except for "Colormap" as I'm unsure yet how to handle it. It looks like
a mix of GimpChoice and GimpDrawable. I guess it could just be both (2 args,
using values from the GimpChoice if GimpDrawable arg is NULL).
And I didn't make the settings in the "Edit Flame" dialog into arguments as I'm
not sure if the "Speed" and "Variation" in particular should be args, or are
just temporary args only meant to construct a flame (in particular, it looks
like it builds data defining the flame?). These data should be their own args
probably?
Maybe we could also have the "file" as alternative way to init the flame data
(the "Open" button)?
For now, I'm just storing the whole settings struct as an aux argument, so that
"Load/Save Settings" work, as well as the initial values from previous run.
Also the whole code is still a bit of a mess. I feel like we could really
simplify a lot of the code, all these values stored globally or duplicated now
in both the GimpProcedureConfig and the control_point structure.
Resolves #9989
In 2.10/GTK2, clicking an already selected toolbutton caused the
background color to change to indicate this action.
This patch restores that behavior through CSS updates.
It also slightly rearranges the CSS to group related button styles.
Since we were not chaining up with parent's finalize(), we were not
removing the instance from the gimp-debug infrastructure which assumed
the object was leaked and would try to read its reference count for
debugging purpose, when GIMP_DEBUG=all was set.
In fact, the object was not leaked, therefore we got into a segfault
when dereferencing already freed memory.
I added a few specific validations for range types (int, double…), and a
generic validation at the end, meant to catch all yet uncaught invalid
argument cases (yet with less details on the what and why).
In Preferences > Toolbox, clicking on an item below the
initial scroll window view causes it to jump to the top
automatically. This patch prevents this by setting the
clicked index in the GtkTreeView before grabbing focus.
I had this one crash upon exit, inside gimp_align_options_update_area() as a
consequence of gimp_align_options_image_changed() being called on an image
change. I could not reproduce after this one time and it's very likely a race
condition when everything is getting finalized, and the tool options object is
getting finalized earlier than the user context.
Anyway this should fix the potential crash.
gimp_procedure_new_return_values() takes ownership of the passed GError (it
allows, among other things, to call it directly as return value). So we must not
try and free it afterwards.
These are stored in the Extended Block. This block also holds metadata
in Exif, IPTC, and XMP formats, but those are not yet implemented in this
patch. A comment stating Exif was implemented in PSP 10 was corrected
to PSP 8 as well.
Changes only to ScriptFu.
The third term (the default) of a SF-FONT etc. spec is now ignored.
Test case is SF>Test>Sphere. There are still crashing issues
related but separate.
Changes were made to the click code for layers & masks
due to the introduction of multi-select, and this seems to
have caused the view highlight to be inconsistent.
This patch adds the gimp_layer_tree_view_update_borders ()
call after a click or selection to fix this.
On Windows, the title bar can be set to light or dark mode via DwmSetWindowAttribute ().
This adds code to update the main title bar and dialogue title bars based on the current theme.
The main title bar uses "prefer-dark-theme", while the dialogue title bars
uses the color of the widget background to assume the correct color.
If we leave a space between the macro name and opening parenthese for argument
lists, the args are not considered macro args (which will be discovered when
using it). I experienced this issue while testing code on some plug-in
yesterday, so thought I might as well fix all these broken macros for casting to
the specific GimpPlugIn subclass, so that we won't have a next time.
The gimp_procedure_run() already existed, though it was with an ordered
GimpValueArray array of arguments. Its usage feels redundant to the series of
gimp_pdb_run_procedure*() functions (which is confusing), but
gimp_procedure_run() was actually a bit more generic, because it does not
necessarily calls GimpProcedure-s through the PDB! For instance, it can runs a
local GimpProcedure, such as the case of one procedure which would want to call
another procedure in the same plug-in, but without having to go through PDB. Of
course, for local code, you may as well run relevant functions directly, yet it
makes sense that if one of the redundant-looking function is removed, it should
be the more specific one. Also gimp_procedure_run() feels a lot simpler and
logical, API wise.
A main difference in usage is that now, plug-in developers have to first
explicitly look up the GimpPdbProcedure with gimp_pdb_lookup_procedure() when
they wish to call PDB procedures on the wire. This was done anyway in the
gimp_pdb_run_procedure*() code, now it's explicit (rather than calling by name
directly).
Concretely:
* gimp_pdb_run_procedure(), gimp_pdb_run_procedure_config() and
gimp_pdb_run_procedure_valist() are removed.
* gimp_procedure_run() API is modified to use a variable args list instead of a
GimpValueArray.
* gimp_procedure_run_config() and gimp_procedure_run_valist() are added.
* gimp_procedure_run_config() in particular will be the one used in bindings
which don't have variable args support through a (rename-to
gimp_procedure_run) annotation.
Passing (name, type, value) triplets is actually useless because we can get the
type information from the procedure/config anyway. That only adds one more
verification to do. Let's just change the function so that we pass (name, value)
couples instead, pretty much like in `g_object_set()`.
As far as plug-in API is concerned, at least the calling API, order of arguments
when calling PDB procedures doesn't matter anymore.
Order still matters for creating procedures with standard arguments (for
instance, "run-mode" is first, then image, or file, drawables or whatnot,
depending on the subtype of procedure), but not for calling with libgimp.
Concretely in this commit:
- gimp_pdb_run_procedure_argv() was removed as it's intrinsically order-based.
- gimp_pdb_run_procedure() and gimp_pdb_run_procedure_valist() stay but their
semantic changes. Instead of an ordered list of (type, value) couple, it's now
an unordered list of (name, type, value) triplets. This way, you can also
ignore as many args as you want if you intend to keep them default. For
instance, say you have a procedure with 20 args and you only want to change
the last one and keep the 19 first with default values: while you used to have
to write down all 20 args annoyingly, now you can just list the only arg you
care about.
There are 2 important consequences here:
1. Calling PDB procedures becomes much more semantic, which means scripts with
PDB calls are simpler (smaller list of arguments) and easier to read (when
you had 5 int arguments in a row, you couldn't know what they refer to,
except by always checking the PDB source; now you'll have associated names,
such as "width", "height" and so on) hence maintain.
2. We will have the ability to add arguments and even order the new arguments in
middle of existing arguments without breaking compatibility. The only thing
which will matter will be that default values of new arguments will have to
behave like when the arg didn't exist. This way, existing scripts will not be
broken. This will avoid us having to always create variants of PDB procedure
(like original "file-bla-save", then variant "file-bla-save-2" and so on)
each time we add arguments.
Note: gimp_pdb_run_procedure_array() was not removed yet because it's currently
used by the PDB. To be followed.
Similar to commit 6905b0bbef for "file-pat-save-internal". For interactive
usage, nothing is changed, but for non-interactive ones, we can now choose a
list of drawables to export.
Pending more changes, relative to the discussion in #7370.
Since now the name of arguments will become more important, over order, let's
name the first parameter "run-mode" even in cases when this is a dummy argument
(most often the case when a procedure always acts the same, whether interactive
or not). I keep the mention of the parameter being useless in the nick and blurb
strings, as it's useful information. But let's keep using our "standard" arg
name "run-mode" for this first argument.
This partially revert some of the changes in commit 652a1b4388 because the
Windows CI suddenly failed because of this (my local build on Linux didn't have
any problem though) with:
> /usr/bin/x86_64-w64-mingw32-ld: libgimp/libgimpui-3.0-0.dll.p/gimpproceduredialog.c.obj: in function `gimp_procedure_dialog_save_defaults':
> /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:2570:(.text+0x633): undefined reference to `_gimp_procedure_config_save_default'
> /usr/bin/x86_64-w64-mingw32-ld: /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:2576:(.text+0x644): undefined reference to `_gimp_procedure_config_has_default'
> /usr/bin/x86_64-w64-mingw32-ld: libgimp/libgimpui-3.0-0.dll.p/gimpproceduredialog.c.obj: in function `gimp_procedure_dialog_load_defaults':
> /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:2549:(.text+0xa2f): undefined reference to `_gimp_procedure_config_load_default'
> /usr/bin/x86_64-w64-mingw32-ld: libgimp/libgimpui-3.0-0.dll.p/gimpproceduredialog.c.obj: in function `gimp_procedure_dialog_constructed':
> /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:368:(.text+0x11b1): undefined reference to `_gimp_procedure_config_has_default'
This is because these functions are used not only inside libgimp but also
across inside libgimpui. As a consequence, the build fails when linking
libgimpui.
This goes with our planned change of not making GimpProcedure arguments order
relevant anymore regarding the PDB API. In particular, it means we don't want to
use GimpValueArray for various procedure arguments API, but directly
GimpProcedureConfig objects.
This change will allow to add or reorder arguments in the future, so that we
won't have to create new PDB procedures when adding new arguments, while still
keeping PDB API stability.
Some of these should not even be visible by libgimp and were just fine as static
as well! For the rest, I make them really private (not only with a private
header).
We cannot be 100% sure generically (i.e. for all possible bindings available
with GObject Introspection) if bindings add their own reference to objects or
not. Clearly we have cases when they always do (Lua, Javascript), cases when
they do only in certain conditions (global Python variables) and cases when they
don't (Vala). What we know for sure is that in these script languages,
developers don't manually manage memory anyway. So the additional reference is
not their fact.
So let's just maintain a list of automatic memory managed binding languages,
among the few we officially support (i.e. the ones for which we have working
test plug-ins) and verify by executable extension if the plug-in is written in
one of these.
Both keeping a manually-updated list and verifying by extension are not so
pretty solution, but for now it will do.
Resolves the second half of #300.
This adds conditional code to the gtk_window_present () call in gui.c
to prevent it from running if the user requested it stay minimized in the shortcut
or commandline call on Windows.
It also keeps the splashscreen minimized in that case.
As explained in the comment above, the reference might actually be owned by the
binding code (not by the plug-in code) and therefore can still be released
afterwards. Freeing it now while we don't own the reference exposes us to
double-free crashes.
This will be needed in particular for GIMP on Windows/Aarch64. Also even on
other OSes, it is useful to support lua plug-ins not only with luajit but also
upstream lua.
This is in part a port of commit 6f921b27bb from gimp-2-10 branch, except that I
could not easily cherry-pick because too much had changed already in the master
branch.
There are also a bunch of additional changes in some other glue scripts.
Also some rules which were in the 2.10 branch don't apply to the main one, such
as Python being copied from the x86 binaries, since clang-aarch64 has Python3
(unlike Python2).
See discussion in #9170 and !1091. It looks like this soon won't be a problem
with a recent llvm-windres (which is now patched). But until then, let's patch
upstream GIMP but only for this build.
Note: the additional `rm` call was done for this error:
> + mv _install-arm64 /home/SYSTEM
> mv: cannot move '_install-arm64' to '/home/SYSTEM/_install-arm64': Directory not empty
I guess the home directory is not properly wiped-out between runs, which is not
a huge problem as long as the runner is private to our project. Let's clean
things ourselves.
In some very hard-to-reproduce conditions, I experienced
tool_manager_selected_layers_changed() running on an invalid GimpToolManager
pointer (because tool_manager_exit() had already run) and therefore segfaulting
on quit. Let's make sure we disconnect the signal handler.
Add Border enlarges an image by twice the specified border size and creates the border in this
additional space. If an image already has the intended final size, this behaviour is not desired.
This change adds a toggle to (dis)allow resizing, similar to the drop shadow script.
This came up in a reddit thread by /u/rapidexchange
https://www.reddit.com/r/GIMP/comments/6csofx/im_new_to_gimp_so_sorry_if_this_is_a_stupid/
Adds code to read in PSP_SELECTION_BLOCK.
If there was an active selection in the PSP file when it was
saved, that selection will now be active in GIMP as well on load.
This is a consequence of commit 98f0c448. Apparently setting the tree view
cursor also reset visually the selection. So I make sure I only set the cursor
on the first path in the list of selected items.
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.
This comes with a "colormap-delete-color" into the "colormap" action group. The
action/button will be insensitive when the selected color is used in the image,
since it is only possible to delete unused colors.
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.
Improper counting of args declared by scripts versus pspecs in a ProcedureConfig.
Scripts don't declare run_mode, while pspecs have run_mode and an extra internal pspec
that is not an argument.
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.
Original patch by @ellestone.
The current tooltip is somewhat confusing for two reasons: It doesn't
mention the word "ICC", leaving room for doubt as to what a "color
profile" might be. And as @TheTooleMan suggested, it's easier to read
and understand if the action (opening a file . . .) is in front of the
modifier (. . . with an embedded ICC profile) instead of vice versa.
bootchk had the case in commit 6781a35668. I again had it with gfig. I think it
just makes sense to init GEGL, especially as the errors are not that explicit
and that the plug-in code may not even call GEGL code directly (so it makes it
harder to guess).
After the recent port.
* contrast-retinex: Initialize format & src_buffer to NULL
* curve-bend and map-object: Remove no longer needed functions
* file-load-gif: Fix C++ style comment
When the selection changes, the focus must be on one of the selected items. Not
doing this was creating a very annoying behavior where you would select an item
in the tree view with the pointer first, but then when moving up/down with the
keyboard arrow, the move originated from the previously set item. This was
because the arrow move used the "cursor path", i.e. the keyboard focus, and not
the item selection as origin.
In our case, let's make sure these match (i.e. the cursor path is the path of at
least one of the selected items, which is the most expected behavior for mixed
pointer/keyboard interactions).
See code in gtk_tree_view_move_cursor_up_down() from GTK code.
Resolves #10119.
If the user sets the "Image Spacing" and "Hole Width" values
to 0, the hole creation code gets stuck in an infinite loop.
This patch adds a check to the allocation code for the hole
to make sure both its dimensions are greater than 0. If not,
then the hole is not created in the first place.
… with another default shortcut.
This won't happen with the standard US layout, but among all the layouts which
exist (or will exist), there is no say that the characters behing <shift>2-5
keys are not another one of our default shortcuts for other actions. We don't
want to print this case, because it is special enough that it's really not a
bug. In this case, we just ignore the transformed shortcut on the zoom action
and be done with it.
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.
If the GIF has a value other than 0 or 49 in its PixelAspectRatio
header, then we now use it to set the non-square pixel resolution.
For reference, GIFs calculate this value like so:
PAR = (Value + 15) / (float) 64.
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.
… description.
- The returned value as width/height/etc. of the glyph extents (or bounding
box), not "of the font" (which doesn't mean much).
- Adding some definition for ascent and descent. This text is straight out
copied from Pango documentation comments in pango/pango-types.h.
- I don't see why we were negating the descent value. Let's keep the value sign
as defined in Pango.
- Fonctions were renamed: s/gimp_text_fontname/gimp_text_font/ and
s/gimp_text_get_extents_fontname/gimp_text_get_extents_font/
- The size_type arguments were removed. Even in 2.10, this argument was marked
as "dead" and ignored. It was only kept for API compatibility.
- The font name (string) was replaced by a GimpFont argument.
gimp_text_font() is easily tested in the Python console with:
> Gimp.text_font(Gimp.list_images()[0], None, 10, 40, "Hello World!", 1.0, True, 100, Gimp.context_get_font())
And gimp_text_get_extents_font() with:
> Gimp.text_get_extents_font("Hello World!", 100, Gimp.context_get_font())
- First do not write the protocol-version (and therefore don't read it either
nor compare it to the current one). This file does not depend on the protocol
version.
- Secondly when reading an unknown identifier, simply print a message on stderr
for debugging/reference, but ignore it up to the next closing parenthese.
- Finally do not use the file-version as a terminal error as well. When we read
a shortcutsrc with the wrong version, we still try to read it as best as we
can. There might be issues, but it's better than fully dropping the whole list
of shortcuts as it's a pretty important file (people might have spent a lot of
time tweaking their shortcuts!).
Fixing:
> [809/2421] Generating libgimp/GimpUi-3.0.gir with a custom command (wrapped by meson to set env)
> libgimpwidgets/gimppropwidgets.c:37: Warning: GimpUi: multiple comment blocks documenting 'SECTION:gimppropwidgets:' identifier (already seen at gimppropwidgets.c:23).
Hardcoded colors don't work well with theme customization (on a dark theme in
particular, it was bad).
Anyway built-in units are already grayed-out and non-editable. I don't think
further styling is needed.
This function is not perfect and in particular doesn't seem usable with binding
because of GimpUnit being some weird mix between an enum and some kind of class.
So this will have to be fixed too. See #8900.
… function gimp_font_get_pango_font_description().
Also updating file-pdf-save which is the only plug-in using these right now.
Note that I am not fully happy with the new function
gimp_font_get_pango_font_description() because I experienced some weird behavior
in file-pdf-save which is that some fonts were wrong if this is called after
pango_cairo_font_map_set_resolution().
But let's say this is a first step looking for improvements.
...and to GimpProcedureDialog.
Also resolves #25 by adding the missing PDB parameters to the GUI.
Note that there are a few remaining tasks:
* The config values are being copied to mapvals.
Eventually the rest of the code needs to be updated
to directly use the config.
* The material tab uses icons from the Lighting plug-in. They didn't show up before the port; this needs to be fixed.
* The drawable buttons are huge compared to the original plug-in. The styling needs to be looked at.
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!
After testing, setting a window as transient to another from another process is
still broken on Windows and it's hard to diagnose without using Windows
directly. Since it's not just broken, but it even hangs the whole process, which
is quite a blocker issue, let's disable again the whole code on Windows.
Converted to GimpProcedureDialog as well, and changed the
string argument for the combobox to GimpChoice.
Some widgets are still standalone and could be further improved
to work with GimpProcedureDialog.
A new aux parameter for upper/lower border area was added so this could be generated
as part of the GUI.
I received warnings about serializing the FloatArray and GBytes parameters, so I did not integrate
the existing variables with GimpProcedureConfig in this current version.
The only missing feature is that we don't constrain the various argument
drawables to RGB/grayscale or to the same dimension as the input drawable. This
could actually be quite easily implemented, either through a set of constraint
flags, or a more flexible callback function (similar to the API of
gimp_drawable_combo_box_new()). It could either be implemented on the argument
level (which has the advantage of letting libgimp handle argument sanity of
plug-in developers, even in non-interactive calls, with generic error messages)
or within the new GimpDrawableChooser API.
I was actually implementing this when I realized that this plug-in works fine
even with images of different dimensions. As for the format, GEGL handles format
conversion automatically. There is absolutely no reason to limit ourselves.
So let's drop this feature for now, because we should not over-engineer. If it
turns out useful and we get requests, we can always create later either a
specialized arg macro GIMP_PROC_ARG_CONSTRAINED_DRAWABLE() or a method to
specialize the widget with gimp_drawable_chooser_new_constrained() for
instance).
This was not working properly and needed some external build script as well as
the stamp/bogus header trick like for other similar in-source generated code.
In the same time, I get rid of old meson code which was meant for when using
meson < 0.57.0 (since our requirement is now meson >= 0.59.0).
I believe it should not happen in normal GUI case (which is when you create a
GimpProcedureDialog). I had the issue while moving around some plug-in code and
moved dialog creation before gimp_ui_init() by mistake. The issue was not
obvious until I followed the trace inside libgimp. This would be even more
frustrating for plug-in developers so let's have a clear warning message giving
the possible plug-in crash reason.
The various drawing APIs are cumulative which is not right when we want to
change a preview (especially if the preview changes dimensions! Then we end up
with pieces of the previous drawing behind the new one).
This new function will allow to reset the whole drawing. Note that we may end up
with some black background if the preview are doesn't have the right dimensions.
This should be improved later too.
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).
Improvements of GimpPickableButton:
- Update the selected pickable live as you choose it in the popup. This allows
for instance to get live preview of GEGL operations while staying within the
pickable popup.
- Store the initially selected pickable (before popping up) so that when one
cancels (either with Esc key or by clicking outside the popup, but not on the
parent button), the button comes back to the previous pickable.
- Properly destroy the popup when the parent widget is finalized to avoid
annoying cases where the popup might still be alive.
Additionally I split the GimpPickablePopup with a GimpPickableChooser containing
most of the GUI, which will make it usable as plug-in pickable chooser as well!
Clicking on the parent (typically a button, as in the GimpPickableButton case
used in GEGL operations' generated GUI) used to emit "cancel". Let's have it
emit "confirm" instead.
Also it makes for a "confirm" interaction through pointer action as there were
none until now (only key "confirm", e.g. Enter or Space keys), unless
implemented in a child class (e.g. GimpPickablePopup would emit "confirm" on
activate-item of the tree view widgets, e.g. when double-clicking an item; that
was not ideally discoverable).
A few minor code style issues were also fixed.
Note that there's only one procedure parameter (Preset name),
but it's not retained between runs.
I want to ask about this before making a full conversion to
GimpProcedureDialog widgets.
This name was really irking me because it's not a button (anymore? Maybe it used
to be just a button). Depending on the specific widget, it will have several
sub-widgets, including a label. And it can theoretically even be something else
than a button.
So let's just rename these widgets with the more generic "chooser" name.
Similar to the latest commits for GimpBrush:
- gimp_pattern_get_buffer() returns a GeglBuffer and allow getting a scaled
version of the pattern.
- Old gimp_pattern_get_pixels() is made private.
- Moved GimpPattern into its own file and store the buffer to avoid re-querying
it through PDB continuously.
No as for the widget to select a pattern:
- Preview frame ensured to be square.
- Default size increased.
- Drawing code using the new gimp_pattern_get_buffer().
- Cleaned up code.
So what I realized was that the core was sending contents without transparency.
Actually the mask was our transparency channel here. Since in most use cases,
what you want to do when you request a brush buffer is to be able to draw it
somewhere, having a buffer already with alpha is much better, even more because
by default, it looks like background color is black which is possibly not what
you expect usually from a brush preview.
If someone wants absolutely no-alpha, it's easy to get rid of the channel. It's
simply better that the default behavior is the most expected use case.
- Increase the default size to 40x40 and multiply it by the current window scale
factor to have decent preview size.
- Make the brush preview always square with a GtkAspectFrame: even though
brushes are not necessarily square, this is a much more obvious size rather
than letting GTK choose a random allocation size which ends up very weird
looking.
- Scale down the brush to the biggest possible dimensions which fit the square
preview area (if the brush native size is already smaller, I don't scale up
though) while keeping aspect ratio: previous implementation was really weird,
as we were only seeing a tiny corner of much brushes as we weren't scaling
them down. Obviously I use new gimp_brush_get_buffer|mask() functions for
this as it supports scaling.
- Implement drawing color brushes too: the previous implementation was only
drawing the brush mask, which was absolutely not what would be expected for
such brushes.
- Add a white background behind color brushes with transparency.
- Simplify and clean up the code.
One of the consequences of this new implementation is obviously that it's
mandatory to call gegl_init() when using this widget.
… and gimp_brush_get_mask().
gimp_brush_get_pixels() was a bit crappy, returning raw data with only
dimensions and bpp to go with (no color model/space, no bit depth…). So the
assumption is that we work with 8-bit per channel data, possibly with alpha
depending of number of channels as deduced from bpp, and very likely in sRGB
color space. It might be globally ok with many of the brush formats (and
historical brushes) but won't fare well as we improve brush capabilities.
- gimp_brush_get_pixels() is in fact made private.
- The 2 new functions are using this old PDB call _gimp_brush_get_pixels() to
construct buffers. This has some limitations, in particular that it returns
only 8-bit per channel sRGB data, but at least the signature won't change when
we will improve things in the future (so if some day, we pass fancy brushes in
high-bit depth, the method will stay the same).
- This new implementation also allows scaling down the brush (keeping aspect
ratio) which is useful when you need to fit a brush preview into a drawing
widget.
- Current implementation stores the buffers at native size in the libgimp's
GimpBrush object, hence save re-querying the core every time you need an
update. This can be improved as current implementation also means that you
don't get updates if the brush changed. This should handle most common use
cases for now, though.
- Also with this change, I move GimpBrush class implementation into its own
dedicated file.
- Move the property widget functions for GimpResource properties into a new
libgimp/gimppropwidgets.[ch] file. This mirrors the files
libgimpwidgets/gimppropwidgets.[ch] which are for more generic property types.
- Rename the functions gimp_prop_chooser_*_new() to gimp_prop_*_chooser_new().
- gimp_prop_chooser_factory() doesn't need to be public.
- Add a label to GimpResourceSelectButton, make so that the
gimp_prop_chooser_*_new() functions set the property nick to this label and
add this label to the size group in GimpProcedureDialog.
… from the plug-in normal runtime crossed streams!
I also add a huge comment in-code, because this was annoying enough to
understand and debug that I don't want someone to remove the idle without proper
consideration and testing in the future, thinking it's useless.
- Removing useless or redundant code.
- Simplifying various logics.
- Using GimpResource directly in temporary PDB procedures, not resource names.
- Better cleanup of the core resource chooser when the plug-in dialog quits (we
need it to ask core to close also any visible resource chooser dialog).
- Replace the "Close" button by more common OK/Cancel. In particular, the
GimpPdbDialog now properly keeps track of the initial object and when hitting
"Cancel" (or Escape key), this initial object is set back.
- Clean up some of the comments, especially when the code is self explanatory.
There is still much more to clean and improve, but it's a first welcome step.
Found by the definitely useful libgimp warnings:
> gimp_plug_in_destroy_proxies: ERROR: GimpPattern proxy with ID 13 was refed by plug-in, it MUST NOT do that!
One instance of `(GIMP_VALUES_GET_INT (args, 0)` was missed during the initial conversion.
This caused a compiler error. The value is now retrieved from the GimpProcedureConfig
object.
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.
Instead of passing a guint32, pass the proper type, since our the HANDLE type
can be 64-bit on Windows (according to links I found).
I was hoping it might be the reason for the breakage under Windows, though I
also found Microsoft documentation saying that the 64-bit handle can be safely
truncated: https://learn.microsoft.com/en-us/windows/win32/winprog64/interprocess-communication?redirectedfrom=MSDN
Nevertheless I'd appreciate testing again from NikcDC or anyone else, as I
reactivated setting transient between processes on Windows.
Note that I also pass the proper types on X11 now (Window), even though guint32
worked fine. Better be thorough.
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.
...and to GimpProcedureDialog.
selection-to-path-dialog.c was also removed as the code can now be contained
within selection-to-path.c thanks to the new API.
… 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).
The various information (width, height, image type and number of layers) are
those of the full image, not of the thumbnail. Make it clear in the docs of
GimpRunThumbnailFunc.
Additionally:
- file-xmc was returning the proper information but variables were wrongly
named, which was confusing.
- Fix file-ico thumbnail proc which was returning the thumbnail width/height.
- In file-darktable, initialize width/height to 0 so that we just don't show any
size when we don't get the information. It's better not to show anything than
completely wrong information (the thumbnail target size).
We were choosing the bigger icon in the ICNS list. Instead let's choose the
bigger icon within the target size bounding box. In case there is no smaller (or
equal size) icon, we falls back to the smallest bigger icon.
Also make sure we set width and height to the full image size, as this is used
as information on the full image (not the thumbnail).
SVG is a vector format which is easy to render exactly within the size×size
bounding box. Let's make sure we do so.
This makes for much sharper SVG thumbnails (and also possibly faster thumbnail
render).
… than a GimpValueArray.
Similar to other GimpProcedure, move to using a config object. A difference is
that thumbnail procedures are always run non-interactively.
Also fixing WMF load thumbnail procedure: the dimension computation was wrong
when the image was wider than tall.
Also the palette argument is now a proper GFile argument (not a string).
There is also a palette argument for the export procedure, but it's currently
unused. A palette storing function will need to be implemented.
Some bit of additional logic cleanup was done.
Again, I am losing a tiny bit of UI, in particular the ratio fields, but also
the update of the size label (this was kinda broken anyway, as it updated only
when updating some fields, not others).
Also moving the default resolution to 300 PPI.
Last but not least, I transformed the "paths" int argument to a GimpChoice
argument.
The new dialog is not fully on-par with the old one. We lost the X and Y ratio
fields as well as the ability to constrain dimensions to each other. This should
be improved when we'll get proper automatically generated widgets for dimension
arguments.
… a GimpProcedureConfig for arguments.
This also factorizes the code to load metadata. By default, a GimpLoadProcedure
will try and load metadata from a file (if Exiv2 knows the format). The run()
function will be allowed to edit the GimpMetadata object but also the load flags
before it is actually attached to the image, allowing plug-ins to have custom
metadata handling code when needed.
This is used in the generated GUIs for GimpChoice arguments, but also for
validation of property setting.
New functions:
* gimp_choice_set_sensitive()
* gimp_string_combo_box_set_sensitivity()
This is just a method to simplify transforming a GimpChoice argument into an
enum value, which is easier to deal with, in C. It also allows to benefit from
switch() warnings or the like to make sure no cases are missing.
Developers won't have to maintain manually a list of the possible values in the
help string. It can now be generated from the GimpChoice and will be therefore
ensured to always be up-to-date, and nicely formatted.
I also add some pango markup to the type helper texts to differentiate it from
the main argument docs.
These will replace the int arguments used in place of enums. The problem of int
arguments used as list of choices is that it makes calling PDB functions very
opaque. This is especially bad when a list is long, so you constantly have to
refer to the documentation to understand what a series of numbers mean in
argument lists.
And the second issue is that plug-in developers have to manually maintain a list
of values both in the GUI and in the documentation string. This help text may
get out-of-sync, may end up with missing values or whatnot. Also if it is used
as tooltips, it makes for very weird tooltips in the graphical interface, with
an overlong technical list of int-values mapping which should ideally only be
made visible in the PDB procedure browser listing.
- GimpLabelStringWidget widget makes any widget with a "value" string property
into a GimpLabeled.
- Add a "value" string property to GimpStringComboBox (which makes it usable by
GimpLabelStringWidget).
This will be used for creating limited lists of strings as argument types for
procedures.
Ideally enums are the best type for this, but it can only be used for generic
libgimp* enum types, not custom enums created only for a given plug-in. For
this, we currently just demote the args to ints which lose any semantic. A
limited list of string will give back some semantic and some better validation,
even though it's a tiny bit more annoying to work with strings than int types
(at least in C).
Also fixes some spelling issues and removes a warning about an
uninitialized variable.
Currently the only argument is for non-interactive mode, so
the dialogue isn't ported to GimpProcedureDialog yet.
The dialog itself is ported to GimpProcedureDialog. However, the
width and height require another API that allows for size entries with
multiple fields before it can be considered finished.
As usual, these got forgotten!
Also colorxhtml is actually deeply broken by commit 89c359ce47 which removed
gimp_drawable_get_pixel() (Niels thought it was not used, whereas it was simply
harder to spot with bindings!).
This will have to be fixed eventually.
I was hoping to redesign further but the whole logic of animated brush creation
is made so complicated that I think it would require a whole more complex GUI
with visual hints. So anyway I stopped at basic redesign and port to the new
dialog generation code.
It still makes the code much simpler and a bit more powerful (also less bugs
hopefully). I have also reviewed the procedure arguments, removing redundant
ones (display-cols and display-rows are just computed from cell-width and
cell-height) and adding some aux arguments instead to simplify dynamic GUI code.
The assert tests were not taking well into account the case where upper == lower
or where it's an integer spin which is just separated by 1 (both cases seem
silly, but it makes sense in the case of generic — or even dynamic! — spin
widgets where we want to adjust the min and max, e.g. depending on the property
of the image, or on other settings.
Now gimp_procedure_dialog_get_label() can work both with an existing property ID
or a new property ID. In the former case, it will simply sync the label with the
procedure argument, which will make it easy to update the label contents. In the
latter case, it just initialize with the provided text.
It's the basic stupid port, though this dialog is so bad that I think I'm going
for a second stage with a basic redesign of this GUI while also moving to
GimpSaveProcedureDialog. To be continued.
The expectation of 2 references per object in gimp_plug_in_destroy_proxies() was
wrong. It is true during most of the plug-in life, because both the
GimpProcedure and the GimpPlugIn have a hash-table keeping their own reference
to it, except that in gimp_plug_in_pop_procedure(), we release the reference
owned by the procedure with _gimp_procedure_destroy_proxies() first. So at this
point of the object life, its reference count is supposed to be 1.
The source of the bug was in fact in _gimp_plug_in_get_*() (where * can be
display, image, item or resource) which was behaving differently the first time
it is called for an object with the successive calls. In the first call only, it
was creating then refing into the table (so the object started directly with 2
references) whereas on successive calls, it just returned the hashtable-looked
up reference. In other words, it behaved as a (transfer full) on the first call
and (transfer none) on successive calls. And so did all public API which were
making use of this infrastructure (in particular gimp_*_get_by_id() functions).
The arg "num-images" is clearly redundant as the "images" array already has this
information. Moreover it is bug-prone, for instance running 'Repeat "Filmstrip"'
would crash the plug-in which was defaulting to NULL "images" and 1 "num-images"
(without any GimpItem serialization ability yet).
Of course, we could just fix this, but better remove the redundant arg and all
possibilities of future similar bugs.
Also I now display a proper error message when running without input images
which says: "\"Filmstrip\" cannot be run without any input images"
The widget_creator_func() given to gimp_prop_chooser_factory() will create an
object which will take its own reference. We must release the one we got with
g_object_get().
Metadata handling is also integrated in this API:
* while giving a possibility to disable metadata saving if you want to do it
yourself (e.g. in file-heif), by setting a NULL MimeType;
* and the GimpMetadata object is added as run() argument, allowing one to edit
the metadata during the run, while still letting the infrastucture handle the
save (e.g. in file-jpeg);
* or to save intermediate metadata with gimp_procedure_config_save_metadata()
(e.g. in file-tiff).
While we definitely should not use this inside app/, because having the private
structure easily accessible as a member is very convenient, it is clear that it
makes for a much nicer public signature. Also the priv member is of no help to
third-party developers using this API to make plug-ins and is better hidden in
such a case.
The dialog itself is ported to GimpProcedureDialog, but the original
plug-in only had one config parameter (Number of Tiles).
Some of the other options might make sense as config parameters
such as the horizontal/vertical toggles and opacity.
I needed a few more GimpProcedureDialog widgets, which I now have. The only part
still not generated in this plug-in is the image selection. This is hundreds of
lines less!
It now has arguments for every usable setting (except "keep-height" which is an
aux arg because it is simulated with a 0 "film-height" in non-interactive mode).
Also the film-height/keep-height default in interactive mode is now much better.
I override the film-height default and set it to be the image's height. This
makes for a much better default at all time.
The "Reset" button in Advanced section is not useful anymore since we now have
the generic "Reset" (to Initial/Factory) of GimpProcedureDialog, though it
actually doesn't work right for the time being, as it fails serializing
GimpFont.
This will be useful for plug-in developers but also for us. Seeing we leak the
config object is often a good indication that something is wrong in our handling
of internal references (since everything relies on the config object in plug-ins
now, in particular all the GUI).
I was clearly confused when I wrote this. The sinking part matters to take
ownership of a reference in the widgets table, but we don't need to ref widgets
again before inserting them in containers. We were leaking widgets and as a
consequence the config object (and as a second consequence, some objects such as
resources for resource-selection widgets).
It would be worth porting when GimpDrawableComboBox widgets can be used as
GimpProcedureDialog generated widgets. Or even better, if the GimpPickableButton
were ported to libgimp to be used by plug-ins (since it's actually a lot more
usable).
I didn't port to GimpProcedureDialog because we'd need first a GimpSizeEntry
generatable widget, which can map to several properties (here for instance 3
width properties).
… working with a GimpProcedureConfig.
These are the easiest ones to port as most of the work was already done (mostly
just some now useless calls to remove).
Same as with gimp_procedure_new2(), I will end up renaming the function to
gimp_image_procedure_new() once all usage of this function will have been ported
to the new function using GimpProcedureConfig instead of GimpValueArray
arguments.
The one in GimpResourceSelect is a very nice example of why using config objects
is much nicer, getting arguments by their name instead of an index (which in
this case had to be tracked down by a private function to handle different
cases).
Also in gimp_procedure_config_begin_run(), make sure we sync the arguments with
the config object first thing, even in interactive and with-last-vals case
(where the args may be further overridden). This was especially important for
Script-fu scripts as the image and drawable were not provided separately, so we
need to make sure that the config file has the right values.
Otherwise we will always try to reuse previous values or use the default,
bypassing the actual passed values.
I encountered this issue while porting file-glob and realizing that the
"pattern" argument was always passed to NULL, ignoring the explicitly set
pattern.
When a procedure has no run-mode argument, we should simply not assume anything
and use the passed arguments (which is what the non-interactive mode does).
A lot less lines for the same functionalities!
This includes improvements too:
* "include-pointer" as new PDB argument;
* settings storage thanks to GimpProcedureDialog;
* it should hopefully work better in non-interactive (though it's untested).
The macOS and Windows screenshots are untested after this change, though they
should still work the same. Please report if there is any problem!
This function allows to change the sensitivity of a widget depending on the
value of another property.
We already had gimp_procedure_dialog_set_sensitive() except it was only syncing
with a boolean property, whereas the new function can compare with any property
type.
This new function is meant to replace gimp_procedure_new() when all plug-in
usage will have been switched.
This function creates the GimpProcedureConfig object on behalf of the plug-in
and calls gimp_procedure_config_begin_run() and gimp_procedure_config_end_run().
This way we ensure that all plug-in calls with successful result are properly
stored without asking the developer not to forget to call these (if a "good
practice" is in fact something we request to do every time, especially for good
user experience, we might as well make it rather a core process).
Advantages:
* Better interactive experience: using any plug-in will result in saved
previously used settings.
* for developers, working on config objects is also much more comfortable than
working on GValueArray;
* step forward for the future macro infrastructure: if we can ensure that all
plug-in calls are properly logged, then we can replay plug-in actions, in
NON_INTERACTIVE with the same settings.
Resolves #10069
Currently, the DDS header information for the width, height, and bytes per scan line
are read in and assumed to be correct. As these values are used for memory allocation
and reading, it would be good to verify they do not exceed the file size.
This patch adds a condition after the header is read in to verify those values. If they exceed
the file size (mins an offset), the file is not read in and an error message is shown.
Resolves #9996.
While GIMP has background-colors set for specific buttons,
it did not have a default button background-color. This resulted
in "random" buttons showing system theme colors like the
[Reload Current Theme] button.
This patch defines a default background-color while leaving the
specific button themes intact.
This adds a border when hovering over icons in various
grid views (brushes, gradients, etc). This makes it more
visually apparent which option you can click to select.
Also refactoring: extract two functions
Add test case scripts/test/register-fail
Catches more registration errors.
Any errors not caught at least will not crash.
Remains to be ported to 2.10, but only a few lines, without the refactoring.
The bug is in fact in GTK. "image-missing" is supposed to never missing since
GTK embeds an icon as GResource. But it turns out that the code is buggy. So if
an icon is missing from GIMP theme, then system theme, then "icon-missing" icon
as well, GIMP crashes.
See: https://gitlab.gnome.org/GNOME/gtk/-/issues/3526
As a workaround for now, let's at least add our own "image-missing", at least in
our main themes (Color and Symbolic, not Legacy). This will make GIMP not
crashing at least by default when another icon is missing.
Of course a crash could still happen if one use Legacy or a third-party theme
and if their system theme doesn't contain "image-missing" as well, until GTK is
fixed.
This localization was added recently but it was not in the installer scripts.
Discovered with unit testing: meson test gimp:build / windows-installer-langs
Though GTK+3 is supposed to take care of scaling fonts with high density
displays, it turns out it is not enough for many, for various reasons (taste,
eyesight, distance to the display…). So we add this additional settings to tweak
further the font size.
With Aryeom, we experimented/discussed both a percentage UI vs. an absolute font
size field (e.g. as they provide in GNOME Tweaks). In the end, we went for a
percentage UI because we realize that we don't necessarily know what is the
current size at all. Mostly you just want bigger or smaller, and don't
necessarily care so much at which value is the font size.
This settings only has a single limitation (that we could find), which is when
used on a theme with widget rules using absolute font-size rules (px, or
keywords such as small/medium/large). As long as the CSS rules are relative
though (either to the parent widget, or to the root size), then it works fine.
Basically a theme hard-coding font sizes won't fare well with this settings, but
since we can consider this bad practice, it's an acceptable limitation.
GTK docs is pretty clear:
> It is a programmer error to pass an invalid accelerator string. If you are
> unsure, check it with gtk_accelerator_parse() first.
So now we verify validity of accelerator strings before using shortcuts from
config files (which can be consider "human input" as the file can be modified).
A first attempt at fixing this was going through the idea of changing the
concept of radio actions, such as allowing an active action in an action group
to be called again. Or having some action in the radio group which can be called
but never set active.
But in fact, I just realized that these zoom actions are simply not meant to be
radio actions. They are not stateful actions, nor are they exhaustive.
I also updated the `other_scale` storage logic. Instead of updating it each time
the zoom changed (which was even broken in some cases, like when changing zoom
through another action), I simply save the last custom zoom value. This is the
one which is reused across calls. I don't think always resetting to the current
zoom value is very useful (if you call this dialog, it's not to zoom to the
current zoom!). Also there was some concept of flagging this stored zoom value
as "dirty" by making it negative, but this was never actually used, which makes
me believe that current logic was not the original intent anyway.
Saving the previous custom zoom explicitly set seems to be a good enough
behavior, so let's go with it.
Resolves #10072.
The current PSP palette loading code does not check if
the file's palette entry count value is below the limit
(G_MAXUNIT32 / 4 due to each color being 4 bytes long).
This patch adds this check and stops loading if the count
is larger than GIMP currently supports.
Resolves #10071.
When reading RLE compressed data, a buffer was allocated to 127 bytes.
However, it can potentially be used to read 128 bytes, leading to a
off-by-one vulnerability. This patch allocates 128 bytes to the buffer
to prevent this from occurring.
This fixes 2 issues:
1. gimp_scanner_parse_string() may fail, which here would indicate broken input.
If it does, the string variable would not be set, so we need to initialize it
to NULL, otherwise freeing it could crash GIMP.
2. The variables set by gimp_scanner_parse_string() must be freed.
While I was testing some fonts I had on my system which were named exactly the
same, I also realized that all their fields were identical (among the ones we
store at least), except for the hash obviously. While the hash is great to
differentiate fonts when we use exactly the same files, there are various
reasons where one could have the right font installed with a different hash
(e.g. a simple reason could be if it was stored in different font formats).
So I'm thinking that maybe we'll want to add more fields in the future (if there
are any more fields allowing to better discriminate among some fonts named
similarly). This commit will allow this version of GIMP to still work when
loading the future serialized fonts with new and unknown fields. The unknown
fields will be ignored but at least it will still do its best to find fonts with
the known fields. Therefore we won't have to bump the XCF format version if we
only add new fields.
Similarly this allows to add the fields in-between, reorder existing fields or
even remove some in the future if we realize something is really unneeded. It's
less a big deal than the ability to add new fields without bumping XCF version
though.
Rather than looping fully over the full list of fonts once more, and
re-computing a second time the same font similarity score (with the risk of
messing up the copy-paste), let's just store the indexes of "most similar" fonts
in the first loop, then only query and check the hash for these.
Resolves #8756 (along with !1065)
The system theme leaked due to the checkbox styling not being
defined for GtkTreeView checkboxes.
The background-image in particular overpowers other settings.
The normal checkbox styling is now specifically applied to
these checkboxes as well.
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.
Resolves #10015.
The border color of the menu checkboxes was not
specifically defined by the CSS stylesheet, causing
the boxes to appear invisible when unchecked in
certain system themes. This defines the border color
to the same as the menu text to ensure visibility.
Resolves #10007.
The menu separator color was not defined in the stylesheet,
so it could vary based on the system stylesheet.
It is now set to @stronger-border-color.
Resolves #10040.
A System Theme leak could cause a large border to be drawn around
the export options at the bottom of the Save Image dialogue.
This patch defines them specifically as 1px border with the
@strong-border-color CSS styling.
Resolves #10000.
The border around notebook headers was not specifically defined in
GIMP's CSS stylesheet, so if the system theme used a different color this
would also change. It has now been defined as @strong-border-color.
The existing CSS was also moved to the same area as the other notebook
header definitions.
Resolves #10020
For some reason, not having the border-radius CSS style set
in widgets inside scrollwindow viewports causes them to have
a giant black order if they're not a full height. This was previously
fixed for GtkGrids. This patch fixes it for GtkBoxes as well, such as
the Procedure Browser description area.
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.
This commit and the ones prior are simple refactoring,
with no intended functional changes.
In anticipation of enhancements 9608 and 8404
which make returned values more scheme like.
Also makes code more readable.
- g_str_equal() doesn't have the proper signature for g_slist_find_custom() so
current code was never processing multiple subfonts in a markup layer text.
- Escape the font name parsed from the XCF. For old XCF format, it could contain
forbidden characters. And even for new XCF files (with fonts names generated
such as 'font123' so there should be no escapable characters), we should not
trust that the XCF/parasite contents is correct. It can be wrong for various
reasons.
- Search for ' font="%s"', otherwise the search-and-replace might catch other
XML attributes. For instance we don't want the font "ultrabold" to match
weight="ultrabold".
- The backward compatibility code didn't have code to stop 2 font name
replacements to chain up, i.e. if a real world font was named "gimpfont123"
and another "gimpfont321" and if our replacement code were to change
"gimpfont123" to "gimpfont321" then "gimpfont321" to something else. In the
end, we'd have only a single font. I am fixing it by replacing " font=" to
" gimpfont=" then only correcting the attribute name at the end. This
intermediate attribute name acts as a "done" flag.
There are 3 fixes here:
1. First, searching for "\"GimpFont\"" to determine whether or not this is a new
format text parasite is not enough, because this string can be found in a
text layer with "GimpFont" only as contents. It will serialize as:
> (text "GimpFont")
Instead search for "(font \"GimpFont\"" which cannot be created as part of
the text contents because of the unprotected double quotes).
2. We must verify that strstr() did not return NULL when searching for markup
delimiters. It may happen if the parasite contents is invalid (we must always
assume it can be, since it's user data).
3. When deserialization of a text from parasite fails (e.g. because parasite
doesn't actually exist or its format is wrong), still make sure the GimpText
has a font (setting the standard one before deserializing). Otherwise GIMP
crashes down the line.
For this, I also had to fix gimp_config_deserialize_object(): the object type
name must be parsed even if an object was already set in a GObject property.
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.
New code uses pango_attribute_as_font_desc() which appeared with Pango 1.50.
Since it's currently present in Debian stable, I don't bother too much and bump
this dependency.
Also let's use the same version for pango, pangocairo and pangoft2. They all
come from the same project/repository, so we must likely expect them to be equal
(if they are not, there is likely a problem).
Previous code was incrementing the similar_fonts count each time we found a
better candidate. So we ended up computing the hash even when we had only 1
candidate with maximum similarity.
Moreover this commit fixes a crash happening with the "standard font". The
lookup name must always be allocated, even when it's an empty string (otherwise
it crashes at free).
Additionally this commit factorizes the code so that gimp_font_get_hash() takes
care of hash computation instead of duplicating code.
Finally I do some code organization.
MR #1011 breaks that because now we have a display name
and a lookup name, so font info is saved in the xcf file,
and when loading, the font which matches these info is used.
This doesn't fix pango markup having the wrong fonts names.
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).
Adds a class "gimp-offset-area-frame" to the frame containing a GimpOffsetArea in resize dialogues.
This allows the styling from 2.10 to be applied to indicate canvas size when resizing layers.
Since GimpOffsetArea is a GtkDrawingArea object, it can't have CSS directly
applied to it - that's why the class is added to the frame instead.
GIMP's .gpl palette format and Swatchbooker's .sbz format can contain
metadata on the number of columns. This value was ignored before;
now the import dialogue checks for this value and uses it.
from plug-in
I get a critical error when calling gimp_text_layer_new and the function
doesn't return a GimpTextLayer:
(file-psd:47120): LibGimp-CRITICAL **: 16:00:59.035:
gimp_gp_param_to_value: type name GimpTextLayer is not registered
Adding the above line to libgimp/gimp.c fixes the problem.
This was a regression appeared with commit 1b3af8a89b. We still don't want to
flush the whole image, but if the selected layers change, we want to flush the
display shell.
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.
For characters outside ASCII:
1. repr is wrong in REPL
2. sharp constant #\<codepoint> fails to evaluate
3. sharp constant hex #\x<hexdigits> accepts invalid UTF-8 codepoints
4. a call to error with such a character eats the output string
Also, changed the repr of ASCII control characters (was #\x7)
to their unicode repr (now a box glyph with hex)
Test framework and tests in Scheme, and portable.
Work in progress. Expect commits for more tests.
Testing framework is stable, more or less.
Add more tests
Add tests layer and layerMask.
test Item methods
More tests, selection
Test memory, vector in TS.
More tests char functions
sharp expr tests
Generating the devel docs fails on Windows because it can't find
Babl-0.1.gir, which is only available for me in GIMP's prefix.
Adding that path with -add-include-path fixes the issue for me.
While `length` is always assigned a value by gimp_color_profile_get_icc_profile (),
some compilers don't recognize this and warn about it being uninitialized.
This assigns six instance of `length` to 0 when declared to remove the warnings.
Exif tags Exif.Image.Artist, Exif.Image.ImageDescription, and
Exif.Image.Copyright were not being synchronized with their Xmp and
Iptc.IIM equivalents in the metadata-editor.
This commit adds synchronization of reading and writing of the metadata.
We adjust the struct for equivalent_metadata_tags by removing unused
fields and adding a field that points to the equivalent Exif tag in
a new struct called exif_tag_info.
On loading of the metadata tags we now also check a limited set of
Exif tags. If no value was set yet, we use the Exif value, or else
we check to make sure both had the same value. If not, print a
warning in the terminal.
On saving of metadata, we now also save to the marked Exif tags, or
if the value is NULL, we remove the tag.
In passing, we also fix two memory leaks by freeing with g_strfreev
temporary string lists.
Dates in Xmp include a time and timezone, so add a default time when
selecting a date since we can't edit time and timezone yet.
So far, we didn't take into account that IPTC-IIM has separate date
and time+timezone values instead of the combined value in XMP for
DateCreated.
When loading DateCreated check if it has the same value as IPTC
values DateCreated and TimeCreated combined. If not, we show a
terminal error and ignore the IPTC values.
If neither Xmp nor Iptc has a DateCreated, then use Exif.Photo.
DateTimeOriginal combined with OffsetTimeOriginal to set an initial
value.
When saving, synchronize with IPTC-IIM by splitting the DateCreated
value in date and time+timezone and save each to the appropriate tag.
Also make sure that for IPTC-IIM the date separator is a '-'.
Adds a bottom margin to the grids because the horizontal scrollbar
was overlapping the bottom-most row of the grid.
Adds wordwrap and left/right margins to multiline text widgets,
mainly to make the text not start right at the edge of the widget.
We were using a string for the metadata mode, meaning we had to compare
string values in a lot of places.
We simplify and probably speed-up comparisons here by replacing the
mode string by an enum value.
The only place still needing the string values sometimes is
metadata-impexp.[ch] where we added a conversion table to convert
the mode to a string.
to fix the issue when 'Standard' can be actual font from the list
or a font which starts with. (ie. Standard Symbols PS)
Fixes: #3104 (GNOME/Gimp tracker)
OpenEXR allows for arbitrary channel names. Instead of failing once the common ones are checked, this patch
checks the number of channels in the file.
If there is only one channel, it is treated as
grayscale (similar to OpenImageIO's behavior).
A debug warning with the channel name is also printed.
When replacing a selection, take and apply markup (if any)
from the first character of the selection for the entered
text.
This fixes the case when you no longer can change the
global layer text properties after replacing the text.
Also, this changes the behavior introduced in #1220.
Fixes: #7948 (GNOME/Gimp tracker)
Organizing sub-dependencies into modules helps. Later if for instance we need to
remove or change OpenEXR, we know that they are related and that Imath can be
removed if we remove OpenEXR.
The targets were just being left floating, and the pre-generated in-tree
source were always used instead
When bison/flex are found, ensure we actually dep on their output - thus
actually running the targets - and only use the in-tree copies as a
fallback
After discussions on IRC with ender/Jernej and frogonia:
* exchndl.dll (drmingw) requires dbgcore.dll and dbghelp.dll which seem to ship
with win10+, but not win7 (we don't know for Win8). So for Win7, Jernej had to
manually add it back (otherwise, building then running on Win10, it looks
fine, but GIMP fails to start on Win7).
* MSYS2 dropped Win7 support anyway and supports now Win 8.1+.
See: https://www.msys2.org/docs/windows_support/
So even though it looks like GIMP works fine on Win7 (after special-casing the
2 DLLs above by adding them manually in the installed files), there might be
unforeseen issues in the long run.
* Win7 official support by Microsoft now ended. And Win8 support is soon to be
(it actually already has, "except for Server 2012 [based on Win8], which's
supported for another 2 months"). Win8 never had much adoption anyway.
* frogonia confirms they didn't see many Win 7 reports, if at all, in the last
year.
So based on all these, and in order not to make our life over-complicated, we
drop Win 7/8 support for the next 2.99 versions and for the upcoming stable 3.0
series.
Though we keep support to these versions in the 2.10 series, in order not to
disrupt current usage too much.
Crossroad repo was finally moved to Freedesktop.
See: https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/477
This should avoid the too many failures we have lately on TuxFamily
infrastructure (and also gives a proper bug tracker for Crossroad). I am very
thankful to TuxFamily for all these years! :-)
Let's not be said that I moved the repo because I don't like this friendly FLOSS
host anymore. I just needed something different for Crossroad project now.
Some fonts which pango identifies correctly, became broken
after renaming them in fontconfig, so the strategy was to
rename only fonts which pango can't see.
To check if pango got the correct font, the PangoFont
has to be loaded from PangoContext, which is costly.
It Turns out that querying FontConfig with more attributes
fixes this. Hence renaming every font doesn't affect
the fonts pango already sees.
We use fontconfig directly to rename fonts to fix some issues
with Pango (see MR !1011), and fontconfig is present on all
platforms supported by gimp (even on windows, pango is build with
fontconfig as a dependency), so it makes little sense to keep this
code path which is now never used.
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.
When changing the width we got a division by zero crash because we
did not consider the case of bpp * bitspp being less than 8.
To fix this we check if bitspp is less than 8 and in that case multiply
the amount of bytes by 8 and then divide by the number of bits per
pixel.
When building using MSYS2 CLANG64 profile using clang 16, we get the
following error (besides other required patches):
../../gimp/app/widgets/gimpwidgets-utils.c:931:12: error: incompatible
pointer to integer conversion returning 'HGDIOBJ' (aka 'void *') from a
function with result type 'guint32' (aka 'unsigned int')
[-Wint-conversion]
For now, let's use the same GPOINTER_TO_INT macro we use in
gimpprogressbar.c. In the end, we need a 64-bit type available to
plug-ins, but that needs more work.
Resolves issue #9809, fix by @mareroqpoland.
When "Separate Layer" is selected, the entire drawable is always
filled rather than using the selection. This patch uses the selection
instead (which will be "all" if there is no active selection)
Looking further, the @help is only used in gimp_proc_view_new() so far (for the
Procedure Browser) where the blurb and argument descriptions are already
localized. It makes no sense to only keep this in English. So let's ask to have
both arguments translated.
Now clearly we should not ask for @help to be mandatory. Very often, it makes no
sense to have a longer help string (the small blurb and the few arguments may be
very self-explanatory). So I make this argument nullable.
There is only the @help_id which I wonder if we could not have a simpler
function gimp_procedure_set_documentation_uri(). Indeed while having a unified
infrastructure with a XML summary and help IDs and whatelse makes sense for GIMP
as a whole, I think that many third-party plug-ins would work much better with a
very simple direct URL. Or it could even be a GFile to a local file (for
plug-ins which want to embed their documentation in the plug-in folder for
instance). To be continued…
I add a new class method deserialize_create() to GimpConfigInterface which
returns the GimpConfig object per deserialization, instead of modifying an
existing bare object.
This matters for cases like our GimpResource (and later our GimpItem) classes
which are fully managed by libgimp and should be unique objects per actual
resource. It should even be possible to compare the pointer itself for identity.
That's why we need to let GimpResource create the object (in reality request it
to the infra and only ref it) through this new class method.
With this commit and the previous ones, all GimpResource are now properly stored
as plug-in settings (e.g. the "film" plug-in has a font setting which is now
properly remembered).
These identifiers are not portable (across various installations and therefore
not for XCF either), but at least they are reasonably identifying data on a same
installation (unlike GimpResource's int ID which is only valid within a single
session) which makes them very fine for plug-in settings storage.
When a data file disappears, we fallback to the context default data instead.
This finds the core resource knowing its type, name, collection and internal
state (in other words, the values returned by _gimp_resource_get_identifiers()).
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.
Rather than reimplementing the same checks for every possible resource data
type, just do it once and redirect to the correct factory container.
For the libgimp API, we leave per-type functions `gimp_*_get_by_name()` (where *
can be brush|gradient|font|palette|pattern so far), but internally they all use
gimp_pdb_get_resource().
Note that eventually we want these functions to return a list of resources as it
should be possible to have several resources of a given type with the same name
(since they are made by third-party who might have had the same idea of a name).
… fails.
This happens for plug-in settings storage. Serialization stops at first failed
property serialization, whereas we could store more. This feels like the last
settings feature is broken.
(except from the aliases "Sans-serif", "Serif" and "Monospace")
The code to get the file path was inspired by code in MR !1011 by Idriss Fekir.
My initial idea was to use FcFreeTypeQueryAll() when adding each font
individually through FcConfigAppFontAddFile() but we were only doing this for
our additional directories (not the system ones) and also before we actually
loaded all the fonts through FontConfig. So this would have required more work
to get right. Though it also means that now the ! USE_FONTCONFIG_DIRECTLY code
path is more broken than ever (as we consider this path information quite
important for plug-ins now).
Additionally to make this work, I got rid of the code making all GimpFont
objects internal data by default, which is nonsense to begin with. Fonts are not
writable by GIMP, sure, yet they are external to GIMP and loaded from a file!
This will be important for an upcoming commit (which is currently in a branch
related to issues #50 and #9250), where we want to implement GimpResource
storage as plug-in settings, because fonts were the only GimpData without a file
and we are using this information to generate a collection identifier.
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.
… the GIMP_DEBUG_FONTS environment variable is set.
Turns out nearly a thousand font files get ignored on my installation (and I
don't install much; a lot of them seem to be bitmap fonts (PCF) in a X11
directory). I still want output so that this topic doesn't get forgotten and
hopefully some day, we can do better. But a single line on stderr (and an
environment variable for details) is enough for 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.
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.
Inline completion is case sensitive, this makes it
broken, because fonts desplayed in the pop should be
quried in a case-insensitive manner.
This fixes #2832.
See gtk issue #275.
We use US English which uses behavior. So we replace all occurrences of
behaviour.
Most notable is File Open behavior in preferences. Besides that several
mentions in function documentation and a few in comments.
...the tab itself. Noted by @user062. This adds a right margin to the
close button on the image tabs so that the tab size is pushed out
to fit the button.
Use the dedicated function rather than comparing strings.
Because of this, menu items for the "windows-display-*" actions were not
destroyed, neither were the relevant images because the proxy menu item was
keeping a reference to the image (for the small in-menu preview in Windows
menu).
It's nearly the same list of placeholders which will make it easier to
third-party developers (though format still changed, devs will have to add
square brackets for section names).
Now some section names are missing because we would need to break some list into
smaller sections yet want to avoid having separators everywhere. This makes me
wonder if removing my first placeholder implementation was the right idea.
Anyway this new implementation is cleaner and we should find a way to add
sub-sections without creating separators in menus.
Also I didn't try to add new section names (though I did once or twice, e.g. a
"Close" section around quit/close actions which didn't exist) but eventually we
should. Being able to name logically parts of the menus will make them even more
organized (if we can't name a group of actions, it may mean we didn't think
properly the organization and order).
Per @ajonsson, gettext does not like < or > used as symbols
and throws a warning. They are replaced with HTML entities
< and > to prevent the problem.
These should be hidden on stable releases and shown on unstable branch. But
we'll also want to show these in the stable branch, outside of release
(typically when we'll be at 3.0.1).
The combo box button is contained within a box element.
The box was also having its background-color set,
so there were small square "corners" around each dropdown menu.
This patch separates the box color from the button color to prevent
this.
"Windows" and "Help" should always be last. New top-level menus (created by
plug-ins, scripts or GEGL ops) will be appended in the order of creation between
"Filters" and "Windows" menus.
There were some mixups between a few representations of menus:
* "_Some Menu" and "Some Menu" should both map to an existing submenu "Some
Menu" (in the GimpMenuModel, the stored path doesn't contain mnemonic).
* The menu item on the other hand should contain the mnemonic and not lose it.
* Not only this, but "Some _Menu" should still map to the same menu, even if it
was already created with a different mnemonic. It means that the first
registered menmonic "wins", as we don't want duplicate submenus with same
title (even if they have different mnemonics).
So this new code is better handling the canonical menu path (no mnemonic, no
section name, no double slashes, no trailing slashes, etc.) vs. the
canonical-with-mnemonic menu path to avoid weird duplicates.
Some additional bugs are fixed where we were creating weird empty submenus
containing the same items as the parent menu as well, or when a submenu title
was a perfect prefix of another submenu title at the same level.
File/Quit, Edit/Preferences|Input Devices|Keyboard Shortcuts should not be in
the main menu bar on macOS because they are already in the "app menu".
See #9322.
- Remove the wiki which is now dead.
- Update the roadmap link and title it in plural.
- Move the "Bug Reports and Feature Requests" inside "GIMP Online/" submenu.
I'm not sure what's the default for random string attribute, but better be
explicit anyway. I think this way, we make sure that gettext won't try and
translate these.
This removes a bunch of inconsistencies we had from the before-2.99.16 version
because new items from plug-ins were all added at the bottom of their respective
submenu.
This will replace the "placeholder" concept where I was using an invisible item
with a label and no action, making it invisible. Instead let's just name
(internally) our sections. This has the following advantages:
* Conceptually more correct: basically we just want to place items among the
same category of actions.
* Easier to search for plug-in developers who'll want to place their plug-in
procedures in menus, because it uses an actually searchable attribute
("section-name").
This is used by the core by allowing a special syntax in menu paths: if finished
by "/[Section]" then the item will be place in the specific section named
"Section". In case one actually wanted to create a submenu called "[Section]",
they can use a double bracket: "[[Section]" and "[[Section]]" will both map to a
normal submenu (not a section name) titled "[Section]".
All other usage of square brackets will not be processed in a particular way.
E.g. "Hello [World]" will end a submenu titled "Hello [World]" or "Bye]" will be
a submenu and so on.
Finally this system is currently limited to the position of the item itself,
i.e. must be placed as last element in the path. In particular, you currently
cannot use it to position a new submenu inside a section. E.g. say that I want
to create a submenu "From Platforms" under the "Open" section of the File/ menu.
This is currently impossible. With this syntax, we can create new items directly
in the "Open" section, or create a "From Platforms" submenu in the end of the
File/ menu, containing our new procedures.
This could be a good improvement to come.
Sphere-designer: Since some of the strings are translated versions, we
can't know in advance how long they are going to be.
Let's use string copy/cat functions that explicitly check the size and
are guaranteed to add a NULL.
- Add modern error handling using GError.
- Check return values of fseek and fgetc for errors.
- Remove most occurrences of g(u)long.
- Fixed overflow issue with maxred/green/blue found with coverity.
I noticed this in coverity. I couldn't find any actual script using
SF_DISPLAY, so the impact probably isn't very big.
Because the enums start at 0, the size of the array should be at least
one more than the value of the last enum, which was not the case here.
Increase the size of the array by 1, so that accessing SF_DISPLAY,
which is the enum with the highest value, is valid.
Resolves #5742.
The check is for a horizontal line (where the Y coordinate
would be the same for all three points), but the X axis was
checked instead due to a copy/paste error.
Resources are stored by the plug-in infrastructure and their memory should not
be managed by plug-in code.
My commit 4f69995b46 was crappy and modified a generated function. I was just
too tired with all the heat in here, I guess!
Similarly to how we handled image items, all resources are handled and stored by
the plug-in infrastructure and should not be destroyed. This wrong annotation
was triggering bindings to unref resources when going out of scope, hence
crashing plug-ins.
Note that in the future, we expect this to be possible to create other brushes
with a same name. Maybe we should have a special function allowing to request
core resources (the ones installed by GIMP itself).
Adding unsupported messages was overwriting the old message without
first freeing it. In addition, the first message was initialized
as a string constant.
We now start with duplicating the (empty) string, so that it can be
freed. We then add a define to reduce boilerplate to add the string
for each unsupported feature. The code in this define takes care of
adding the new message and freeing the old message.
Make sure we use gsize for intermediate results to not get integer
overflow on large image sizes.
This still is not ideal, but better than a crash, since we may (try to)
allocate a very large block of memory, which we should eventually fix
by looping over smaller size buffers.
Brushes can't be large enough to actually cause overflow here, but
since the result is gsize, it can't hurt to have the intermediate
results to gsize too.
Though I didn't encounter this bug in my commit 54b22c717a, 2 unit tests are now
failing with:
> Bail out! Gimp-Widgets-FATAL-CRITICAL: gimp_ui_manager_update: assertion 'GIMP_IS_UI_MANAGER (manager)' failed
I am assuming this is a consequence of this code I just changed.
This GTK widget code could be reach from a thread calling gimp_image_flush().
Yet all GUI-related code must happen in the main thread (also even though
actions are not GTK code anymore, they can trigger GUI updates).
No issue happened from this so far (that we know of), but a trace by SBDaule for
their growing layer project showed that we'd reach this code if calling
gimp_image_flush() from the paint thread.
It looks like we left out the multiplication by 3 when passing the
colormap size to get to the number of bytes in commit 89c359ce
This fixes a crash when saving an XPM file
Fixes: https://gitlab.gnome.org/GNOME/gimp/-/issues/9711
After 59cb3e36, the GimpOverlayFrame that contains
the on-canvas text editor is still partially visible as a dot.
This patch now hides and shows that as well based on
the "Show On-Canvas Editor" option.
Resolves #9676.
Per @pixelmixer and @programmer_ceds's research,
setting the color attribute on the switch's image children
removes the 1/0 labels on non-System themes.
This was introduced in commit 95fa902827. Unfortunately Gitlab web UI is really
not good at showing indentation issues (or any other space coding style issues,
for that matter).
This results in an infinite loop and there is no change done, so no reason to
flush anything. Mitch had a fix for this (probably the same, per the IRC
discussion), but I really wanted to just release GIMP 2.99.16. So Mitch, if you
read this, sorry for not waiting for you to push this one!
We already search for a compatible Python version in the root meson file, no
need to look up Python 3 again in the PATH, each time we run an external Python
script in the build.
This should hopefully fix #9687.
See: https://gitlab.gnome.org/GNOME/gimp/-/issues/9653#note_1780587
Looking at MSYS2 logs, it looks like they very recently "fixed" the search paths
for lua files, which in turn broke our workaround (searching in subdirectories
of bin/ instead of share/ and lib/).
This should work better (though untested) with the workaround removed now.
Commit on luajit package at MSYS2:
703c7bae2f
In commit 48c27770 some unicode related changes were made. As a result of
that on Windows display_device, which was previously a duplicated string,
is now referenced directly.
However, the g_free was not removed, causing a crash.
We resolve this by removing the obsolete g_free.
Switching to the cfitsio library's fits_read_img () function in 03ea666f
caused RGB FITS images to be read in upside down per SiriL developers and
NASA standards (odd, since cfitsio is maintained by NASA). This flips them back.
The Microsoft style guide and other places online suggest that using a
hyphen is recommended between a number and the related word, when modifying
a noun, so let's do that in our Image -> Encoding submenu too.
The developers of SiriL sent me some RGB FITS images that rendered incorrectly
after d4f42076. These must be read in as
planes rather than individual rows.
The creation of the BMP welcome images for the Windows installer (part of
-Dwindows-installer=true build option) fails in the Windows job. After much
debugging, I could run GIMP, yet it was not enough. One of my hypothesis so far
is that the environment variables for DLLs won't work, since all the DLLs must
be in the same directory as the main binary (though with the WSL thing, I am
unsure, maybe it is still supposed to work), which only happens once GIMP is
installed. So GIMP runs successfully but not plug-ins.
Anyway I wasted too much time working on this and without a local Windows, it
just takes too long (mostly testing thanks to the CI) and is frustrating. Let's
just move to building both the localization files and the images on the main
Debian job (gimp-meson-debian), then use these as dependencies of the
win-installer-nightly job, i.e. when building the installer.
The common order logic for list of directories in environment variables is that
left paths have precedence. This is at least the case for LD_LIBRARY_PATH (and
probably GI_TYPELIB_PATH too).
Make sure that our local libraries and introspected binaries (in the build
directory) are used and not any version installed on the system or by previous
`ninja install` calls.
This was a first attempt at fixing this error on the CI:
> Cannot open display:
Though it was not enough (see next commit calling plug-ins as non-interactive
when called without interface), it is still a useful change overall.
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.
… being installed.
There is already most of the main code logic for this, though now plug-ins need
to be in their own subdirectories, which breaks for plug-ins/common/ and
plug-ins/python/, while I needed plug-ins in both these categories to generate
the Windows installer welcome images (file-png, and python-fu-eval in
particular).
Once again, meson was not very helpful, since all its functions still refuse to
output generated files in subdirectories, so I end up duplicating plug-in files
with a custom Python script.
This should fix the CI. It was working on my machine as GIMP was installed, but
such a build rule should work even without GIMP installed.
This will also be useful in the future when we'll want to run unit tests of
plug-ins through the finale GIMP binary itself.
After discussion with Jernej, InnoSetup should now work better with rescaling
a big image properly to the window size, yet the ratio should still matter.
Apparently the welcome image is a hack and this is why it requires specific
ratio images. We don't use the big size yet, but since Jernej told me which
dimensions are expected, I already added the code for it to make it easier
later.
So anyway this code would allow us not to have to commit welcome images each
time, which are basically resized copy in BMP of the splash screen, slowly yet
surely filling up our repository with image duplicates.
After all, we develop a scriptable image editor! We should use it to edit images
and export in expected formats!
I only use this script for the devel installer for now, for testing and see how
it goes.
While some packages may be needed only when building (and others only when
packaging), we should probably have a shared list of packages needed for both
steps so that we avoid discrepancies which lead to missing libraries in our
installer.
See: https://gitlab.gnome.org/GNOME/gimp/-/issues/9653#note_1777596
Even though it's just for 3 dots, this may actually be formatted differently in
different languages. Let's not assume we all share this punctuation mark.
Fixes several missing declaration warnings because in fact of missing include,
such as:
> warning: no previous declaration for ‘console_editor_new’ [-Wmissing-declarations]
Fixes 2 old-style definitions:
> warning: old-style function definition [-Wold-style-definition]
The previous commit did fix one such reason (multiple separators next to each
other), but I realized there is one other case where single separators are just
too big: when the menu is embedded in a GtkHeaderBar, each separator would have
a weird margin of several pixels (at least in my case, probably taken from the
underlying system theme). And worse, this margin was using another background
color.
So anyway this CSS rules takes care of not adding weird margins to menu
separators.
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.
Though not a bug, this change will get rid of the following warning:
> app/dialogs/module-dialog.c:291:28: warning: ‘location’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> 291 | text[INFO_LOCATION] = gimp_module_is_on_disk (module) ?
… to long format of unit names.
We can clearly see that the main part of the widget is correctly resized but not
the popup. Unfortunately we don't have access to the popup widget which is
private data, so the best workaround I found so far was to pop the menu down and
up, which basically provokes a redraw to the correct size after contents change.
This fixes MR !385.
There was a bug in commit ca6b58e970 which went under the radar. The gimp
variable was not set at creation, so this line was crashing:
> container = gimp_data_factory_get_container (text->gimp->pattern_factory);
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.
In our use case it is necessary to save the transform matrix, and the
easiest solution is to make the label selectable. If we print the
whole matrix into a single label, formatted with tabs and linefeeds,
then the whole matrix can be copied with a single operation.
This adds a new boolean to text options, "Show on-canvas editor".
When toggled, it immediately hides (or re-shows) the current
text layer's on-canvas text editor.
It uses the same signal and function as the "use-editor" property.
With more recent logic, not all actions are inside the application's action map.
We need to look up actions in our GimpUIManager.
This fixes failing to find the actions with the "text-editor." prefix (in the
text tool editor's toolbar).
Resolves #9636.
gimp_object_get_name (gimp_display_get_image (display)) returns NULL
instead of the filename. documents_raise_display was changed to call
gimp_image_get_imported_file () or gimp_image_get_file() instead to
get the actual filename.
When porting depth-merge to GimpPlugin in 5154b271 the return statements
were not fully replicated. As a result, the depth-merge function was
called even if the dialogue had been cancelled.
This patch adds the missing return statements to prevent this.
Half of the smaller dimension seem a better value, since once we reach any half,
it means we will compute using all pixels anyway. Any width higher than this is
useless.
Adds a check to cast resolution to an int if units are pixels,
rather than calling gimp_unit_get_scaled_digits().
This prevents a LibGimp-CRITICAL about "_gimp_unit_cache_get_digits:
assertion 'unit >= GIMP_UNIT_INCH' failed"
Since commit 89c359ce47, it's supposed to return a GBytes, yet it was returning
raw data (probably intermediate hacking state which was not properly cleaned
up).
It was crashing for instance GimpDrawablePreview widgets at drawing time.
Partially resolves #7211.
plug-in-ripple is a wrapper for the GEGL ripple effect. GEGL allows for
double values for period and amplitude, while the GIMP PDB only allows
integers. This patch aligns the datatypes.
Note that Angle and Phi are still limited to the current design.
For all the test-ops thus far in gegl, gimp:menu-label has been
the same as title + "..", to keep the number of duplicate strings
that need to be translated and the number of needed boiler-plate
lines of meta-data in GEGL down, this is the default behavior when
a title key exists.
The checkbox label wasn't included the :hover CSS, so its background
color didn't change. This created a "box" around the label without the
highlight color when the mouse was over it.
My previous commit was improving the case where we just get many "dirty" signals
and successful inhibition. But if the inhibition request was failing, we would
just retry again and again.
This new version will hold off on on requesting the inhibition for the next 10
minutes. Then it will try again, in case the failure reason might have been
temporary.
… the reason message changes (i.e. when number of dirty image changes).
Some actions in particular would trigger several "dirty" signals, there is no
reason to uninhibit then re-inhibit repeatedly. And as a more general rule,
there is no reason to do so even for different actions while we are not planning
to update the inhibition reason.
It may not be the main reason for #9446 (because if it hangs for several
minutes, there is likely something going on, deeper at the dbus call level), yet
it would definitely alleviate the issue (dividing the wait by as many times as
the dirty signal was emitted!).
The RGB histogram shows three histograms overlaid on each other.
This multiples the pixel and count attributes by 3. To correct this,
the result of gimp_histogram_get_count () is divided by 3 for the
pixel and count displays.
Resolves #414.
Currently GIMP only loads the palette colors used in a GIF, discarding
the rest. This can cause issues when a consistent palette is required
(e.g. a video game sprite or background).
This patch uses either the global or local GIF max palette value to set
the colormap size, thus retaining the full palette on import.
Rename fields of ConsoleInterface more desciptive
Add c,h files for object editor and history
Extract object ConsoleEditor
Extract object ConsoleHistory
Extract TotalHistory methods
As @bootchk noted, gimp-file-load-layers does not check the result of
file_open_layers () but the final return variable
which is always NULL at this point in the function.
This patch corrects the problem so it checks the proper variable.
The order of GIMP_PROCEDURE_SENSITIVE_DRAWABLE |
GIMP_PROCEDURE_SENSITIVE_DRAWABLES was reversed in
gimp_procedure_set_sensitivity_mask (), which caused scripts using
SF_ONE_OR_MORE_DRAWABLE to crash.
… the main instance.
Note that it doesn't say if the batch command succeded, only if they were
successfuly communicated to the main process for processing.
When passing an application ID (which is necessary for application inhibition to
work, i.e. logoff/reboot/shutdown inhibition), GApplication will try to ensure
process uniqueness, which will trigger a new activation to an already running
process. Since our current code assumes that the application can be activated a
single time only, this was what was triggering a whole lot of errors (on the
first running process) in #9598 because there was all the initialization code
which ran again, whereas it was not supposed to.
This doubly-running initialization code was also what completely messed up the
session files, hence broke the GUI after a restart (#9599).
Therefore passing G_APPLICATION_NON_UNIQUE advertizes we don't want GIO to
handle process uniqueness for us.
Note that this is actually a very interesting feature which we have had in GIMP
codebase forever. It would be interesting to kill all our own uniqueness code in
favor of GIO code (and let them handle/maintain passing command line arguments
from one process to another, for all possible platforms). So I added a TODO for
this (for now, we just ignore this feature as it doesn't work well with current
codebase).
Additionally to the F1 shortcut, a secondary icon is now shown in the
action search entry. It works exactly the same as F1, i.e. that by
default, it shows the action search manual page (when nothing is
selected), or the manual page for the specific action currently selected
otherwise.
The default F1 result (if no action is selected) is to show the generic
help page for the action search. If an action is selected, it will show
the specific help for this action.
Since we are already building a static (build-only) libapp, to be used with
tests or tools, let's also use it for the main (GUI) executable.
For the CLI executable though (gimp-console-2.99), we must re-compile
libapp_sources from scratch anyway, because we define the additional macro
'GIMP_CONSOLE_COMPILATION'.
While Debian testing is the sensible choice for dependency requirements while we
are in full-dev mode, now we are getting closer to 3.0 release, and Debian 12
"bookworm" barely got out.
If we continue to develop at current pace, GIMP 3.0 should be released before
the next stable Debian, so we should not use dependencies unavailable on the
latest stable (otherwise GIMP 3.0 won't be distributable soon enough on Debian,
nor on Debian derivatives such as Ubuntu, Mint, etc.).
This is why we are now basing GIMP dependency requirement on Debian bookworm.
We'll likely get back to the next "testing" after GIMP 3.0 release.
Now that we don't blindly generate a messy list of all non-special cased actions
in Filters > GEGL Operations, "GEGL Graph" is all alone in this submenu. It just
makes sense to bring it back to the Generic submenus where it used to be.
Instead of unconditionally add all the non-special-cased GEGL operations into
the menu, only insert the ones which explicitly use the new "gimp:menu-path"
GEGL key.
See new operation "gegl:adaptive-threshold" added in commit 7c2a70eee for such
an example.
Note that the other operations will still get their own generated action (which
means for instance that you can still search them through the action search and
that you can create custom shortcuts for your favorite actions). But now you
won't get an overlong generic list of non-organized actions in a single submenu.
Some people were finding this messy when they had a lot of custom GEGL ops.
Also it means that GIMP doesn't assume that any custom GEGL op is usable in
GIMP. Indeed some ops are really not meant to be used as filters, which is why
we have the gimp_gegl_op_blacklisted() internal function; but this cannot apply
to custom operations. Therefore from now on, instead of GIMP guessing, operation
developers will have the say on whether their op should show in menus and in
which menu path exactly!
Moreover the "gimp:menu-label" key will be used as short label, i.e. the label
which is used in menus in particular, where the menu path is a helpful context
(hence allowing to use shorter menu labels).
The main "title" will still be used as long label, for places where there is no
such context, for instance the action search.
When reverting commit d51c64ec06 and reimplementing as fa2e9adc29, the code to
make sure the generated per-op action name is unique disappeared. This code
ensures that the action name is indeed unique, otherwise the action will
override a previously registed action, which could be made from a plug-in, or
even by another GEGL operation. Indeed, while GEGL operation names are supposed
to be unique, they are post-processed to be valid GIO action names. So it is
totally possible to have 2 GEGL ops with different GEGL names, yet the same
GAction name.
8bpp and below ICO formats use a 1 bit mask for transparency.
When imported the mask is treated as an additional transparent color.
If the icon used the max palette (e.g. 2 colors for a 1bit icon),
the default export format will become larger than necessary.
This checks if the layer still has 1 bit alpha, and subtracts the
mask color from the count.
This patch does the following things:
- An option "Merge menu and title bar" (this is hopefully more understandable
than calling it "Client-side decoration" or again "header bar") is added in
Preferences > Image Windows. This option triggers the restart warning.
Moreover when checked a small warning message will tell that in some cases, it
may not work (there are feedbacks of people having 2 title bars when using GTK
applications using CSD).
- For the reason evoked above (sometimes 2 title bars) and also because the CSD
concept seem really to divide people a lot (some love this as much as others
hate this), this new option "custom-title-bar" on GimpGuiConfig is FALSE by
default.
- When the option is checked, the image windows will use a GTK header bar
containing the menu, the window title (image name and information) as well as
the usual minimize/maximize/close buttons per your OS conventions.
- Since the header bar is set to be hidden when maximizing, if you checked "Show
menubar" for the "Default Appearance in Fullscreen Mode" in Preferences >
Image Windows > Appearance, the menu will be moved to its "old style"
position, i.e. above the canvas. This makes the menu possibly visible (if
relevant option is checked) even in fullscreen mode.
- I tweaked the Default theme to show the header bar with minimal height,
because I find GTK default theme's headerbar height unreasonably high
(especially if the point of the header bar is to save screen space). I am
unsure if this was the right move though, because maybe the default theme
should not do such choices (maybe this should go in the Compact theme?).
I don't see a reason why the quick mask menu was sharing the same
manager as the image menu (the main top menu and on-canvas). This was
why it was receiving all notifications to create menu items on <Image>,
as registered by plug-ins.
Giving it its dedicated manager makes sure this doesn't happen.
This reverts commit 3a35974e3a.
This is not the right fix for the issue (which was happening on the
Quick Mask menu specifically) because root menu models are set with a
NULL path. So forbidding root menu models to handle new subpath means
preventing plug-ins to register new top-level menus.
The correct fix for the issue on the quick mask menu will happen in a
coming commit.
See issue #9586.
In commits a6756b515b and 23da44e3c8, newer API of librsvg were used, over our
current minimum requirement. The reason why we don't bump this requirement is
that librsvg 2.40.x are the latest versions which are full-C. While we have
nothing against Rust, it is not available on all existing platforms, and we
really want to have GIMP buildable everywhere, while also have SVG support
always present (even though it's a vector format, it's an important one in
graphics work nowadays).
See issue #6821.
So in the end, let's keep the old minimum requirement, but test against librsvg
version to compiler either with old API or new one. The changes are limited
enough that it's not too much a bother.
...trying to get the index. Resolve #9568.
The color picker tool calls this twice if you're in Add to Palette mode,
and the editor's color may not be set the first time it's run.
This adds a check to ensure the color is set before trying to retrieve
it from the palette to prevent a CRITICAL.
Don't set both a branch and a commit, otherwise flatpak-builder will
compare the HEAD of this branch (which may evolve with the commit).
Fixes:
> Failed to download sources: module qoi: Git commit for branch master is dfc056e813c98d307238d35f7f041a725d699dfc, but expected f6dffaf1e8170cdd79945a4fb60f6403e447e020
The layer resize to selection and crop to content menu commands were
using the same help ids. This made it difficult to have them both listed
separately in the index of the manual.
Since we use separate help ids everywhere else for menu commands, let's
give each its own help id here too.
Though this doesn't make a problem in normal use (AFAICS), we have crash
in a unit test in CI because the action_factory object was apparently
invalid when calling gimp_action_factory_delete_group().
Because of this, the script was failing to get the version string, which
in turn was breaking InnoSetup.
This fixes the following InnoSetup bug:
> Error on line 116 in C:\_r\_builds\k3_3muaB\0\GNOME\gimp\build\windows\installer\gimp3264.iss: Value of [Setup] section directive "VersionInfoVersion" is invalid.
This commit makes no real changes but style.
As discussed, this makes it much easier to compare commit diffs, rather
than an overlong line where you have to search which package may have
been added/removed/changed.
Resolves #9560.
The Simulation Intent and BPC widgets in the Preference Dialogue needed
to be connected to their properties with `gimp_prop_*` when created to
show the saved default image values.
It does absolutely nothing except sitting there, providing an is-a
relation (both ways because GimpData is its only subclass). This will
simplify having more libgimp API on GimpResource, without having to
add different PDB code for app and libgimp.
This replaces the various GimpHSV/GimpCMYK .aco palette conversions with
Babl.
As a result, it now possible to support importing CIE Lab palettes
(colorspace 7)
Much like for images and items. Change the PDB to transmit IDs
instead of names for brush, pattern etc. and refactor a whole
lot of libgimp code to deal with it.
modified: libgimp/gimpplugin-private.h
The Extensions dialogue assumed that it had a header bar. Since this is
not always the case, conditional checks were added to prevent
GtkHeaderBar code from running. This also fixes a crash when you
double-click to expand the extension description.
The name of the nl-filter plug-in in the manual was recently changed to be
more in line with its description.
Since that is already the name of the plug-in file here, let's also update
the name of PLUG_IN_PROC to be in line with this.
Use g_idle_add() instead of g_timeout_add(300ms), which makes
it respond instantly, while still keeping the actual zoom
call out of the slider callback.
Fixes #9500
By doing `gimp_display_shell_pointer_grab()`, we actually prevent events
from a tablet coming through. There doesn't seem to be a reason to use
it and it's not regressing in functionality either, so let's just remove
it.
Fixes: https://gitlab.gnome.org/GNOME/gimp/-/issues/8016
Some images have Exif.Photo.PixelXDimension and Exif.Photo.PixelYDimension
metadata tags in addition to Exif.Image.ImageWidth and
Exif.Image.ImageHeight (mainly tiff images). So far, we were not updating
these optional tags, meaning they could get out-of-sync with the actual
dimensions when resizing and then exporting the image.
Since these tags are non essential, we will only update them if they are
already present.
This way we handle all kinds of proxies (particularly buttons).
Also add a small hack that prevents extended multiline tooltips of
GimpButton from being overwritten by gimp_action_update_proxy_tooltip().
If "data" is a GimpItemTreeView or a GimpImageEditor, we REALLY want
only the image from these dialogs, even if NULL, and NOT some other
image from a display or context that randomly is around anyway. Fixes
the sensitivity states of lots of buttons in these dialogs.
According to the ::drag-drop GTK documentation: "The call to gtk_drag_finish()
can be done either directly or in a “drag-data-received” handler which gets
triggered by calling gtk_drag_get_data()"
The GimpToolbox's vbox handling DnD chooses however to do both, the drag-drop
handler is calling gtk_drag_get_data() and invariably calling gtk_drag_finish()
to hint that the DnD operation is ending. While this worked in practice in X11,
This is a harder either/or in Wayland resulting in the transfer being cancelled.
In order to behave better wrt the documentation, and make DnD into the toolbox
work on both X11 and Wayland, avoid the first gtk_drag_finish() if the data is
being requested, and only bail out if no offered target matches what the widget
can handle. The handling done indirectly through gimp_toolbox_dnd_init() and
gimp_dnd_*_dest_add() will take care of finalizing the DnD data transfers
successfully.
Closes: https://gitlab.gnome.org/GNOME/gimp/-/issues/7373
Apparently this has never worked until we refactored our menus, now it
suddenly does but not as originally intended. Simply remove the
accelerator and let only the canvas event handler deal with the Tab
key. Restores 2.10 behavior which was quite ok.
Fixes #9352
distress-selection.scm uses gimp-image-set-active-channel which has been
removed causing script failure when a channel is selected instead of a
layer.
Use the new multi-layer aware gimp-image-set-selected-channels and also
use the gimp-item-id-is-* functions instead of the deprecated
gimp-item-is-* functions.
In GimpLayerTreeView, set the action states using GimpActionGroup
instead of using gimp->app directly to look up the actions ( after
trying to get the Gimp from a NULL GimpContext).
Fixes #9433
What we call "System" theme should have very minimal edits over the
actual system theme. So let's drop all the "font-size" properties (one
"larger" one, but especially the many "smaller" ones).
This means that the "Default" theme also will keep system font size.
This is as discussed with Ville and Liam, the later saying he can barely
read dockable texts because of this.
On the other hand, we use "small" font size as a general rule in the
"Compact" theme, which is especially meant for people who want a compact
theme.
The Default theme may have been a bit too dark. Instead let's have it a
tiny bit lighter (and also foreground color a bit less white).
For now, the old "Default" dark theme doesn't disappear totally and is
moved to a "Darker" theme as we have been discussing and wondering on
whether this is prefered by some people (it is). Aryeom also thought a
darker theme may be a good idea.
Moreover Liam actually thought that losing some of the contrast
(especially with the text a tiny bit less white now) is not desired in
his case where eyes may not be as sharp as they used to. Therefore a
"High Contrast" theme may be needed.
Aryeom also suggested that sliders to choose colors could be a much more
generic solution, which might be possible yet would require more ugly
hacks generating on-the-fly theme changes (we do something similar for
dark theme choice already).
This is all work-in-progress and a result from Wilber Week 2023 work.
… for Windows.
Though it's useless for actually building the GIR files, we still need
this package now, for building script-fu with introspection abilities,
to generate GIMP and GEGL enums.
See the 2 previous commits for more information.
This allows our script-fu plugins to use the GIMP enum values, just like
all our other plug-ins know them.
In other words:
* Names are consistent with those of other plug-ins
* Introspectable enums are automatically added as they are added to the
introspection file, without even needing a recompile
* No need to keep track of our enum types anymore, as that is just a
redundant implementation of introspection in practice. This in turn
will let us simplify some of the pdb code
Currently, patterns are loaded as-is - if the full pattern is larger
than the preview, its cut off and you only see the left corner.
In those cases, the pattern is scaled using gegl_buffer_get ()'s scale
parameter.
and Plug-in/Procedure Browser size.
gtk_widget_set_size_request () is applied to the dialog, as it does not
seem to bubble up from being applied to individual elements.
The existing 2.10 width/height values are used.
getting rid of using the the deprecated pointer grab API.
Since there is something fishy and gtk_get_event_widget(event) always
returns the GtkInvisible we grab on (not the actual event widget), we
just steal the "find widget at pointer" code from gtkinspector and
find the help widget that way.
The height of the boxes was never determined by the preview but by the
label+entry, causing vertical padding around the preview. Now the
preview fills the area in more cases, at the cost of a few less
horizontal pixels for the entry.
gimp_toggle_action_real_toggle(): set "active" before emitting
"change-state" so we don't infinitely try to set the state in case of
a recursion.
gimp_toggle_action_toggle(): add notify("active") because it wasn't
done anywhere.
Fixes #9392
GLib has a specific type for byte arrays: `GBytes` (and it's underlying
GType `G_TYPE_BYTES`).
By using this type, we can avoid having a `GimpUint8Array` which is a
bit cumbersome to use for both the C API, as well as bindings. By using
`GBytes`, we allow other languages to pass on byte arrays as they are
used to, while the bindings will make sure to do the right thing.
In the end, it makes the API a little bit simpler for everyone, and
reduces confusion for people who are used to working with byte arrays
in other C/GLib based code (and not having 2 different types to denote
the same thing).
Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
Our metadata library exiv2 only registers the most commonly used xmp
namespaces. Other namespaces need to be explicitly registered. We did not
read or try to store these namespaces, which caused a lot of warnings about
"No namespace info available for XMP prefix '...' and then we could not
process that metadata or save/export those tags.
We had to wait for gexiv2 support for registering/reading namespaces, but
that was added in gexiv2 version 0.12.2 (and the "try" version in 0.14.0).
When reading xmp metadata we process all namespaces and add them to our
metadata xml when we haven't seen them before in the same image.
A GHashTable is used to keep track of the prefixes we have seen before.
The new namespace xml tag is skipped in older GIMP versions, but will be
used now to add the namespaces when exporting images with xmp metadata.
TIFFs with PSD layers can be saved in either Macintosh or IBM PC format.
IBM PC section labels are reversed and the integers are Little Endian.
We now check for 'MIB8' sections and reverse the necessary values so
that the PSD plug-in functions can handle them.
In !769, I accidentally removed the ability to paste into an empty
workspace with Ctrl+V since I added a "does image exist?" check before
the `edit_paste_as_new_image_cmd_callback ()` call.
This patch resolves the issue by moving the check after the
"paste as image" function call.
"Hold and Modify" ILBM images use control bits to increase the palette
beyond what's stored in the CMAP chunk. This patch checks if
HAM mode is set and then interprets the plane bits accordingly.
This commit converts `GimpModuleDB` into a `GListModel`. This allows us
to drop quite a bit of custom code to have an adaptive list of modules
by just becoming a `GListModel` implementation.
Next to that, this commit also rewrites `GimpModule` to use the `notify`
signal for its 2 new properties: "auto-load" and "on-disk", rather than
trying to define a custom signal for that. This in turn allows us to use
basic methods like `g_object_bind_property()`.
Finally, the module manager dialog now uses `GtkListBox`, which can
easily bind to that new `GListModel` infrastructure.
Use a `GtkListBox` to show the list of GIMP themes rather than a
treeview. The idea is that we can expand this a bit more to give a
preview of the theme later on.
In case someone passes a `GtkWidget` rather than a `GtkWindow` as a
parent to a `GimpDialog`, we still have another way of trying to get its
parent window, using `gtk_window_get_toplevel()`. If we still get a
window from that, it allows us to still specify a reasonable
"transient-for" value for our newly-made `GimpDialog`.
Certain XMP metadata tags currently can't be saved by us until we get
support in gexiv2 for adding new structs not present in exiv2.
We remove these tags from the exported metadata because the XMPSDK in
exiv2 would otherwise fail to write all XMP metadata.
Examples are the newer (2019, 2021, 2022) sample images from the
IPTC Photo Metadata Standard.
We also add all the static functions present in gimpimagemetadata-save
at the top, which had been forgotten in the past.
Resolves #5742.
From fa0a0212, the splash's upper text was scaled to PANGO_SCALE_MEDIUM
both when the image width was 2x or less than 2x. This was likely a
copy/paste issue, as the lower text code scaling does not duplicate.
This patch fixes it by changing the else condition to scale to
PANGO_SCALE_SMALL.
Note that this change is unlikely to be seen as it requires a very small
splash screen image to reach the else condition.
As GdkRGBA stores colors as doubles rather than guint16, the assignment
code had to be moved into the ifdef block as well.
Note that this code is only used if X11 is not available on build.
These five plug-ins already used GimpProcedureDialog when I originally
worked on them for !9250. However, their export GUI needs to
use GimpSaveProcedureDialog instead.
1. gexiv2_metadata_has_tag with gexiv2_metadata_try_has_tag;
2. gexiv2_metadata_set_exif_thumbnail_from_buffer with the "try" version.
For a while now the minimum gexiv2 version for the master branch is 0.14.0,
which means we can replace these deprecated functions, since the new
versions were added in 0.14.0.
We were using fixed size buffer with strcpy/strcat, which gave warnings in
coverity.
Even though in our case there was no chance of buffer overflow, let's
replace this by using g_strconcat, which allocates memory for the
string which we free after use.
Also get rid of a few unneeded memset's for strdata.
Let's make cfitsio an optional dependency, showing up in the final configure
output. The file-fits plug-in will just not be built when the dep is missing.
Per @Jehan, this solution would prevent default icons from being loaded
in custom themes if they did not include their own version.
The only thing kept from !909 is the replacement of hardcoded strings
in a few files with constants defined in gimpicons.h.
Switch to NASA-maintained cfitsio library for loading/exporting FITS images.
This allows us to import compressed FITS files (GZIP, HCOMP, PLIO, RICE) in
8/16/32 bit and float/double precision. It also simplifies export code using
the built-in cfitsio APIs.
It is actually available in the SDK but was removed from the runtime (relatively
recently, it would seem). As a more general rule, it seems that GNOME is phasing
it out slowly in favor of libappstream. So probably we should do the same
eventually.
Yet for now, to at least have a working nightly flatpak, let's add it to our
package.
The flatpak_ci_initiative.yml template we include got changed 2 days ago,
replacing the "only" by a "rules", which broke our CI file.
Cf. commit 193f63c20f87d38868c05beee6446b387b73e140 in repository citemplates.
The present commit should (hopefully) fix this error:
> Unable to create pipeline
> jobs:flatpak-nightly config key may not be used with `rules`: only
(even though the error is a bit cryptic, the problem is apparently that both
rules: and only: keys cannot be used together)
… clean-exiting on all dev code (whether stable or unstable branches).
This is because the dirty exit prevents the on-exit crashes which seem to happen
somewhere in the memory cleanup (which apparently corrupts memory but all crash
traces don't show the proper area where the issue actually hapened). So let's
have release exit the process without issue (at least all important user-facing
data is saved properly by then), while not hiding the issue to developers.
Also on dev code, the GIMP_DIRTY_EXIT will allow to go anyway for the quick
exit() path, so that for instance one can work on other pieces of code without
feeling bothered by the constant crashes on exit.
For the record, the crashes we are talking about appear when you update to a
recent GLib, after the removal of GSlice implementation (which is basically now
just a malloc/free alias). There may be issues in our usage of GSlice though we
also experience crashes even just with commit 69e9ba80e on GLib which hints at
issues in our GObject/GType code.
xcf_save_prop() starts with va_start(), hence must end with va_end(). Yet any of
the xcf_write*_check_error() macros could end this function abruptly. Therefore
I'm adding a "cleanup" argument to the macros, allowing to add any code
necessary to clean the current function before returning.
- Missed a necessary autotools change: forgot to remove ui/Makefile
from configure.ac
- Not all compilers allow declaring variables in a case statement without
putting them in a block, so we add a block now.
Instead of loading the GtkBuilder .ui file we now create all widgets in
code.
Added several support functions to reduce code copy/pasting and making
additional widgets and supporting more metadata easier.
The overall layout should still look the same, with a few exceptions:
- Each notebook page only uses one grid. This makes it possible to align
all data entry widgets.
- Featured Organization and it's code were two treeviews next to each
other. These are now organized below each other to make automatic code
generation easier.
- Since we needed to touch this code anyway, I also fixed Xmp.dc.creator
and Xmp.iptcExt.ModelAge to be multiline. This closes #7286.
- The old icons used for the date button, add, and remove row buttons
were replaced by gimp-grid, list-add and list-remove.
Since this was the last .ui file used in GIMP plug-ins, we remove all
files from the .ui subdirectory and references to that.
Note that there are several more places where GtkBuilder is used, but
those cases uses strings defined in code instead of .ui files.
We had a lot of duplicate code using gexiv2_metadata_try_set_tag_string
and then checking for errors.
Simplify this by re-using the existing set_tag_string function by
introducing an extra parameter that tells us whether or not to clear
the tag first.
It was a temporary code added before relevant code landed in babl. The necessary merge request landed in Babl some time ago, and Gimp now requires Babl version 0.1.98, which includes the needed commit.
Related to merge_requests/509
In the master branch we depend on gexiv2 0.14, so we can remove the
deprecated functions and replace them with the "try_" versions.
We can't backport this, since our stable branch has a lower dependency
for gexiv2.
This ports the Import and export dialogs to use GimpProcedureConfig.
It covers all properties except GUI-only options
(which were still ported to libgimpui rather than direct GTK calls)
Additionally, a warning was fixed and mnemonics were added to the
property titles.
The metadata-viewer uses a GtkBuilder .ui file to create the interface.
In GIMP we prefer our interfaces to be created in code and these builder
files are also not available anymore in GTK4.
This commit removes the .ui file and support code, and creates the
interface from code in our plug-in.
Five icons in the Layer dockable were being replaced by GTK defaults at
runtime. A "gimp-" prefix was added so that GIMP's version would always
be used. A few dialogues were fixed to use constants rather than
hardcoding the filename, to make it easier to update the icon in the
future.
In 2.10, print_temp_proc_name () took in the image id. When it was
updated to take in GimpImage, it still assumed the g_strdup_printf
parameter was an integer.
This is fixed by calling `gimp_image_get_id ()` on the image parameter.
While testing the DCX import MR I saw that one image (abaddon.dcx) was not
recognized. This image uses 4 planes with 8 bpp while we only support
3 planes. The 4 planes type includes an alpha channel.
A few small changes allow us to also load 4 planes by allowing 3 or 4
planes instead of only 3.
Photoshop can save metadata when exporting to tiff or jpeg, including
a thumbnail that we can't update. This can contain sensitive data, so we
should not export it. See issue #8383.
To do this, we add the two Photoshop specific tags that we know of to the
list of tags that should not be exported, so they won't be saved.
This allows file-psd-load-metadata to show a warning message like the
PSD plug-in does when unsupported features are loaded.
As PSD metadata does not store rasterized versions of fill layers,
a new option is added to show these layers are dropped entirely unlike
with PSDs.
The dialog title changes based on which plug-in called it.
This adds the PSD metadata plug-in procedure call to the JPEG
plug-in, as part of implementing issue #7549.
Also implements the import half of issue #1842.
JPEGs only store image-level metadata like paths.
This adds the PSD metadata plug-in procedure call to the TIFF
plug-ins, as part of implementing issue #7549.
Also implements the import part of issue #2921.
TIFFs can have both image and layer-level metadata.
The load_paths() function was removed, as the PSD plug-in should
handle this now.
Creates a new public procedure that can be used by JPEG/TIFF files to
load any PSD-formatted metadata they have. This consolidates code
to the PSD plug-in, and lets JPEG/TIFF get immediate updates as the
PSD plug-in improves its own metadata support.
Note that only Macintosh formatted metadata is currently supported
by the PSD plug-in; IBM PC formatted metadata is reversed and not
yet interpreted.
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.
Some valid PCX/DCX files wouldn't load because the bytes per line
header check can be off by one due to integer division rounding.
This adds 1 to the equation to account for this.
DCX files are containers that store up to 1023 PCX files.
The PCX plug-in is rearranged to allow reading multiple PCX images per
file, rather than assuming there's only one image.
GimpFrame has a property 'line-spacing'. gimp_frame_get_label_spacing ()
tried to access it as 'line_spacing', so it always returned 0.
Fixing the typo should now return the true spacing value.
After testing a bit more, I realized that the thread was constantly re-rendering
the thumbnails, even though I didn't touch the "white-background"
button/argument.
This was not just a completely invisible problem, it actually affected the page
selection (it was very hard to select pages by clicking on them, it was randomly
working, and more often not selecting anything). This is how I realized there
was a problem.
The reason was simply that I was never actually calling g_cond_wait() because of
a first_loop flag I forgot to set.
Note that docs of g_cond_wait() explains that it is possible that "spurious
wakeup" happen. At first I thought I had this issue, which is why this commit
also adds a boolean flag to check after a wakeup, to make sure that I was in the
"condition met" case and not the "spurious wakeup" one.
Even though I realized afterwards the real reason was much more stupid, I still
left this additional check.
Fortunately this issue doesn't seem to affect the 2.10 code. Or to be more
accurate: the continuous render very likely happens there too, yet it doesn't
break page selection interaction with GTK+2 as far as I can see.
Port commit 41f40f530a from gimp-2-10 branch to the main branch:
While at first, the idea of always loading PDF with transparency seemed good
(commit 7aff7e9c70), I realized that a lot of administrative PDF (generated with
text and vector graphics, rather than scans or alike containing raster) actually
have transparency. So now all these documents load with transparent background.
Clearly all the office software are assuming that PDF readers will fill the
background with white.
So add a checkbox to decide whether or not to fill the image with white. I don't
update the PDB procedure. I'll just do this on the main dev branch (while also
updating a bit the code to newer API).
Fortunately I regularly open such PDF documents with GIMP and could witness this
no-transparency expectation before we released GIMP 2.10.34! 😅
As side changes, I also:
* ported file-pdf-load to work with GimpProcedureConfig arguments instead of
GimpValueArray;
* ported the dialog to GimpProcedureDialog and generating as much of it as
possible (except for the page selector/preview, and resolution entries);
* renamed the "pdf-password" argument to "password";
* added the "target", "antialias" and "white-background" procedure arguments.
A few issues which would deserve to be looked at more closely in the future:
* adding "width" and "height" arguments and decide how to handle "resolution";
this will likely be better handled with a new GimpVectorLoadProcedure subclass
to support vector formats in particular;
* shouldn't page selection be handled in a better way? Probably this could be
handled by adding a generic logic in GimpLoadProcedure (as multi-page support
is a common feature across image formats);
* GimpInt32Array arguments ("pages") can't be stored anyway right now.
* the "target" arg should be an enum.
This fixes:
> app/core/gimpitemlist.c:632:7: warning: ‘g_pattern_match_string’ is deprecated: Use 'g_pattern_spec_match_string' instead [-Wdeprecated-declarations]
The new function appeared in GLib 2.70 which is our current minimum GLib
requirement, so the replacement is fine.
Generated actions are not necessarily application-wide actions ("app." prefix of
detailed action name). As is the case here, they can be actions specific to a
group only.
With our old code, we needed dummy actions for every submenu. This is not needed
anymore. Actions are only for end menu items (items which actually do something,
not just open a submenu).
Get rid of them all, as well as the code to ignore any action ending with such
suffixes in action-listing pieces of code.
Especially some remnants of when Gimp(Toggle|Radio)Action were not descendants
of GimpActionImpl and had to reimplement GimpAction interface.
Also fixing a few details here and there.
This helps make sure we break circular references as soon as possible when
destroying an action group. I also steal the pointer before freeing objects to
make sure the list is empty immediately and any further signal from the actions
won't affect this group.
Note that it will only work for a model attached to a GimpMenu. In particular,
it won't work for the menu bar set to a GtkApplication with gtk_application_set_menubar().
In other words, it won't work on macOS where we let the OS handle the menu.
Use this for the "View > Zoom" and "View > Flip & Rotate" submenus which used to
display the zoom level and rotation angle. This regression is now fixed.
Though it actually worked in some cases, and failed in others (I have not
figured out which build option exactly makes the format with hole work anyway),
printf manual actually explicitly says:
> There may be no gaps in the numbers of arguments specified using '$'; for
> example, if arguments 1 and 3 are specified, argument 2 must also be specified
> somewhere in the format string.
This explained while it was crashing GIMP (again, only with some build options,
or lack of build options):
> *** invalid %N$ use detected ***
There were 2 possible solutions for this: either ensure that the order number is
always used, but that defeats the purpose of plural localization. Instead I
reorder the argument so that the file name (which must always be shown for sure)
is first in arguments. This way, even if the order number is sometimes omitted
(be it in English or in any language), we avoid the crash.
gimp_rectangle_options_fixed_rule_changed is called when either the
checkbox or the dropdown for Fixed Size is changed.
However, the "fixed-size-active" property was not updated until after
it ran, so the toggle behavior is inverted.
This checks to see if the toggle was changed and updates the boolean
before setting the size field as (in)sensitive.
The GimpProcedureDialog API allows int and double SpinScales. However,
it calls gimp_prop_widget_set_factor () which requires doubles.
A conditional check for a double property was added to this call.
A check was also added to ensure int properties have a factor of 1.0.
Just "Layers" or "Patterns" was always very confusing. It was even worse when
both tools and dialogs had nearly6 the same name (for instance "Gradient" was
the tool action, but "Gradients" was the dialog).
Now these dialog actions will be labelled more obviously in the action search,
such as "Layers Dialog" or "Gradients Dialog".
Of course, the short name will stay in contextualized menus, such as in the
"Windows > Dockable Dialogs" top submenu, or in the Dockbooks' "Add Tab"
submenu.
While the short label can be "Gradient" for instance, because it is in the
submenu "Tools > Paint Tools", this is a confusing label say in the action
search.
Now the longer label will be used in there and will say:
> Activate tool "Gradient"
"edit-paste-as-new-image-short" and "vectors-selection-to-vectors-short" were
just duplicate of the action named the same, except for the "-short" suffix, and
the only point was to have different labels.
Not though that this time, it was not enough to conclude that the action in a
menu shoud have the short variant. These were both used differently depending on
the menu.
Instead I added the concept of "label-variant" attribute in .ui menu files. When
the "long" variant is set, then we simply use the longer label.
There is still one more "-short" action: "tools-by-color-select-short", but I am
a still unsure how to handle this one.
All Gimp*ActionEntry (except GimpProcedureActionEntry) now have a short_label
member.
This commit doesn't add any new short label yet. It just fixes the struct usage,
and fixes a few localization contexts here and there when I saw such broken
strings.
I also fixed a few gradient editor action strings which were not proper labels
(like "splitmidpoint" or "splituniform", or missing uppercase, etc.).
The short labels are just the file names as we have all the context in the menu
to understand what these actions do (in Windows menu, ordered by view position
and with a `Ctrl+n` shortcut next to each, increasing by position).
In the action search for instance, we keep a 'Show "<image name>"' label.
Also I'm adding a relevant tooltip to further explain what each of these actions
do, using the view position.
Basically actions in menus should show the short label (we assume the menu
position brings contextuality) when available, whereas it will use the longer
label in GUI lacking contextuality.
As a first such usage, the `file-open-recent-*` actions have the file name which
will be opened as short label. This is used in menus since the submenu `File >
Open Recent` ensures that the action which will run is perfectly understandable.
On the other hand, in the action search, the action is named 'Open "<file
name>"' since an action named only with a file name would not be understandable.
Since we now generate actions for GEGL ops, we might as well generate menu items
for these too.
What I did:
- Move the "GEGL Operation…" tool (generic dialog with a drop-down list of all
non-ignored GEGL ops) to Tools menu.
- Create a "GEGL Operations" submenu in Filters > Generic.
- Move "GEGL Graph" to the top of this new submenu.
- Generate a new menu item for each generated action tied to a GEGL plug-in,
alphabetically sorted.
Though the GEGL Operation tool is still useful as a generic dialog, let's
generate also per-operation (the ones not ignored and not already special-cased
in the rest of the GUI) tools and actions.
These "tools" are mostly hidden (e.g. not selectable in toolbox where it would
be a bit useless as they would show with the generic GEGL icon or none), but
they can be searched with the action search, shortcuts can be assigned and they
can be added to menus.
Since the recent changes, these 3 tests are not working:
- tools
- session-2-8-compatibility-multi-window
- session-2-8-compatibility-single-window
(the 2 latters were only working with xvfb anyway)
I could just dig further as I did a bit these last few days, and tweak more and
more the testing code. But I think our current unit-testing framework is just
non-reliable and for all these years, we have spent more time fixing the tests
than actually relying on them to tell us there is a bug in GIMP.
Furthermore creating new tests is so cumbersome that basically none do it.
I have a plan laid out in #9339 for a much better and more reliable unit testing
infrastructure, based on the GIMP executable itself and a very simple syntax to
create new test scenari (so that even non-developers should be able to create
them eventually). So until then, let's disable these tests and stop wasting
time.
Same as ZoomIn/Out keys, these are implemented as secondary shortcuts to actions
"windows-show-display-next" and "windows-show-display-previous" respectively.
See issue #637.
- The `accelerator` variable is a NULL-terminated array, allowing up to 3
accelerators per action (so far, none has more than 2).
- Only the struct GimpProcedureActionEntry still has a single accelerator as I
don't think it makes sense that we change the plug-in API to allow a plug-in
to register more than 1 shortcut for a procedure (e.g. we don't want a plug-in
to just register all possible keys for their procedure!).
Of course, users will still be allowed to register more shortcuts for plug-in
actions through the shortcut dialog. It's only the initialization which
1-shortcut max for procedure actions.
- Remove all actions ending up in "-accel" as these were only a trick to
register more shortcut for a same action. Now we just have the real
possibility (rather than creating bogus duplicate actions). As a consequence,
these actions accelerators have been moved as secondary accelerator to their
main action.
The deleted actions are: "view-zoom-out-accel", "view-zoom-in-accel",
"view-zoom-16-1-accel", "view-zoom-4-1-accel", "view-zoom-2-1-accel" and
"view-zoom-1-1-accel".
… Default Values" buttons in Preferences.
I considered just deleting the "Remove all shortcuts" action, because really I
am wondering how useful (and often used) it is, and if we are not over-featuring
the shortcut code.
I could find the origin commit 6da388be93, from 2006. Basically the use case is
for people who want such a different mapping overall that it's much better to
start from a blank slate (e.g. DVORAK users, like in the original report).
See: https://bugzilla.gnome.org/show_bug.cgi?id=331839
So in the end, I just reimplemented this with newer code.
Also this commit fixes the "Reset Keyboard Shortcuts to Default Values" code.
This was always confusing to people that they had to click "Save" then "Close".
With new code anyway, any change is instantly put into effect, and the only
point of "Save" is to actually store immediately in the shortcutsrc file. But
this is clearly not very clear to people (and it can be done in the Preferences
dialog too).
Instead let's just have a "OK" button. The file will be actually updated on exit
only (if "Save keyboard shortcuts on exit" is checked). And that's it.
The only missing feature would be the ability to cancel the latest changes
before hitting OK, i.e. having a "Cancel" button too. Let's see to do this
later.
Also get rid of various old references to menurc and don't install it anymore to
etc/ (neither the new shortcutsrc as it doesn't look like it brings much value
to do so).
This uses a new concept of "default shortcuts" which must be called only once at
most per action. Any subsequent shortcuts setting are custom settings.
Commenting these lines out is mostly informational as it allows to see in a
quick glimpse in shortcutsrc file which are custom shortcuts or not.
gtk_accel_map_load()/gtk_accel_map_save() are not working with the new
GAction-based code. GtkApplication does not seem to have helper functions to
simply load and save accelerators in a file, so we just implement it ourselves.
A few things are missing right now, namely:
- On parsing, it doesn't handle any kind of duplicate accelerators (possible
especially if someone edited the new shortcutsrc manually).
- On reading, maybe we should only write down the changed (from defaults)
actions, while keeping the old ones commented-out, as menurc used to be. This
is actually useful info both for debugging or even for users who want to look
at this file and see what they changed.
- We should add import code to transform the menurc into shortcutsrc when
updating GIMP, otherwise all custom shortcuts would get lost.
There is still the question on whether we should add the group name too. I think
we should, expecially for plug-in's procedure actions, though right now these
are just added in the GtkApplication's main action group anyway. I'll see later
to refine this.
Now that we don't have any action duplicated in groups based on names (i.e. that
there could just be 2 actions with the same name in different groups), let's
have the GimpAction also store its group.
Use this to fix some code which was now crashing when confirming erasing an
existing shortcut.
In particular on macOS, we want to show some default common actions (see
comments in !837) but gtk_application_prefers_app_menu() docs says that it will
always return FALSE on this OS. So we ignore this call on macOS.
Depending on where it's used, this list of action can be either in the
"dockable" or the "dialogs" action group.
The meson rule is a bit more complicated than I wished it were because of the
ever-so-blocking lack of simple dependency in meson.
Cf. my latest comment: https://github.com/mesonbuild/meson/issues/8123#issuecomment-1496168759
This deals in particular with the dockable issue. Each dockbook needs its own
GimpUiManager and the action groups inside, which are identified by a string
identifier but also by a different user data (allowing to identify the specific
dockbook an action was call from, so that for instance you close the right
dockable).
It also makes the name requirement of plug-in procedure more flexible as a
procedure name clash can only happen between plug-in procedures now (not with
core actions).
This is a continuation of previous work where we are slowly moving to most logic
being in GimpMenuModel so that it works both when we create menus ourselves or
when we let GTK do it for us (e.g. the main menu bar in macOS).
It should make it possible to attach an action group to a widget, instead of
making it global to the application. This will be useful/used for context
actions, such as actions which are only relevant to a dock and which will
therefore be duplicated to each dock (with the specific dock as user action so
that we work on the right part of the GUI).
I have not implemented all virtual methods. Not sure if they are all necessary.
It was actually working fine except that I wrongly named the submenu somehow,
but even more particularly I thought it was about single dockables (tabs)
whereas it was about full detached docks (a window containing several
dockables/tabs).
As a further optimization (even though the big slowness situation is
mostly resolved anyway by a previous commit), let's not rebuild whole
submenus when only a few items were added or removed.
1. First make so that the action "visible" property is only notified
when the visibility actually changes. This way, we can trust that the
visibility of the item and of the related action are properly synced.
2. Now when an action which is part of a model changes its visibility,
we trigger the proper "items-changed" only for the added or removed
item. This replaces the old procedure of removing then adding
everything (i.e. a full reset).
3. Add some utilities in gimpwidgets-utils (out of gimpmenushell.c).
This cleans up some code and also fixes some bugs which were
reimplementing (badly) some code I already implemented (right) in a
static function.
4. Fix adding new actions in sub-sub… menus. Previous code was only
showing the direct parent, not up to the root menu (this could happen
for plug-in procedure items in particular).
When an action is removed from a group, we verify if it's not in any group
anymore. If so, we remove it from the GimpApp action map.
This fixes some CRITICALs happening when some actions were dynamically deleted
and re-created, in particular the "windows-display-XXXX" actions.
These were the last use of the old GtkAction API and it was particularly
annoying here as this widget is used both in core GIMP and in plug-ins, yet core
GIMP actions were not GtkAction anymore (so the "activate" signal handler's
signature was different, which would crash the core code).
Now the clash is resolved as this widget just uses GAction (which both
GimpAction, for core code, or GSimpleAction, for plug-ins, are).
This is also the absolute last use of GtkAction (and other related API) in all
our code (core, libgimp* and plug-ins). \o/
I've hesitated if we should make it a GActionGroup, whose API handles actions
fully through name strings. I didn't see what it brings us short-term compared
to the additional work, so for now it's just a class of its own, not
implementing GActionGroup interface. Maybe later.
Pre-GIMP-3.0 code logics would re-allocate several GimpMenuFactory or
GimpUIManager for no good reason. While it was still working with old GtkAction
code, with our new GAction-based code, we were ending up overriding an action
with a new version of the same action, while keeping reference to old actions.
This made for discrepancies of the enabled or visible state of actions.
The new code keeps singleton of some objects and references to already
registered GimpUIManager or GimpActionGroups objects and make sure no actions
with the same name are created twice.
Unless mistaken, this is not needed anymore. New GtkApplication code should take
care of creating the native macOS application menu for us.
Cf. also contents of MR !558.
Testing the 2 code paths is otherwise extremely annoying. Let's just add an
environment variable allowing us to run one or the other implementation if the
variable is set.
Since GAction don't have labels or visibility, it is up to every application to
fill the GMenuModel with such infos. In my previous implementation, I was simply
handling these in GimpMenuShell subclasses (GimpMenu, GimpToolbar and
GimpMenuBar) since we need them for tooltip support (unavailable from GMenu).
Nevertheless there are cases where we want to use GTK API directly with a
GMenuModel, in particular with gtk_application_set_menubar(). This is necessary
to handle the macOS specific code path, where we don't want our usual menu bar.
This OS has its own display of a software menu bar, directly in the desktop GUI.
See !558 for some screenshots of this.
So this commit moves around some code away from GimpMenuShell subclasses into
the new GimpMenuModel class. Now we use this new class instead of simpler GMenu
objects. It handles syncing with GimpAction-s, auto-updating labels, visibility
and sensitivity, as well as adding custom items (plug-in actions, recently
opened files, opened images, etc.).
Only remaining API are action group-related.
While doing this, I also remove 2 debug actions which don't look like they were
outputting any information anyway (at least on the main dev branch):
"debug-dump-items" and "debug-dump-managers".
In such a case, we may not want to connect to "query-tooltip", yet we still want
the normal tooltip to show up. This was a case for instance for the recently
opened file actions ("file-open-recent-*") or opened image actions which were
not showing their tooltips.
When we do this, their actions are not properly run, because this happens after
the "hide" signal. So we need to detach the popup in an iddle function (so that
it runs after all in-progress signal handling happen), which will in turn
removes the last reference to the object.
My last commit message was slightly wrong. I had one last special case to
handle: the ability to only create sub-GimpMenuShell (i.e. at a specific path
other than the root).
We are using this ability in particular for tool options submenus.
It's still pretty simple now and allows to add toolbar buttons and separators
(at start or end). There is no possibility of runtime-customization yet, but in
the future, it would be great to allow such ability and use this widget for a
main window toolbar which people can customize to add quick access to their
favorite actions.
Somehow the toggle actions were not working correctly on GimpMenu popped up e.g.
as dockbook menus (but it was fine in the GimpMenuBar). I straightened up the
code to be a bit clearer. I also rely on the "toggled" signal rather than
"change-state" (the latter is supposed to happen before state change actually
happen). It now works much better.
Several menus can be triggered either as popups on their own when right-clicking
the dockable or on items, or as a submenu in the docks main menu.
In the former case, we want the menu items to be at the root level, whereas in
the latter case, we want them inside a properly named submenu.
To handle this, I wrap these in a properly labelled <submenu> in the .ui files,
and I add a boolean flag to gimp_menu_shell_fill() which will drop the top
submenu if and only if this is the only top item. I use this flag only when
using these menus as popup menu on their own.
Also fixing a few memory leaks around these pieces of code.
… group name.
The gradient editor submenu add 2 submenus with changing names. It was using
again bogus actions: "gradient-editor-blending-func" and
"gradient-editor-coloring-type" do nothing except for being used as name
holders.
Instead I add the concept of group name for GimpRadioAction-s and when I use a
radio action attribute as <submenu>, this submenu will use the group name (and
sync with it, if it changes).
I only translated the undo menu into GtkBuilder's .ui format for now.
The only missing part is that the icon is now shown.
Note that in various parts, I don't rely anymore on a bogus menu action (i.e.
"undo-popup" action in this case) which does nothing but has an associated label
and icon. I simply add the label and icon as submenu attribute directly in the
.ui file, which is translatable and whose strings should be parsed by gettext.
Eventually I'll just get rid of all the various "*-popup" or "*-menu" bogus
actions.
The new GimpMenu is derived from GtkMenu. Both GimpMenu and GimpMenuBar are now
implementing GimpMenuShell which allows to share a lot of the logic for filling
the menus, adding items, etc.
This is less and less a GtkAction. Note that I don't implement
gimp_action_get_name() because once we will drop completely GtkAction and make
GimpObject the parent, we can just use gimp_object_get_name().
The dialogs-menuitems is shared between dockable-menu and image-menu, just as it
was with the old format. For this, we use XSL transformation with XInclude, then
drop the namespace (because GTK doesn't like the unknown namespace being defined
and crash immediately otherwise).
This is a placeholder which is not meant to appear in the menu. Our new system
uses placeholders internally, but plug-ins cannot make use of these.
Not sure anyway if this is so useful in the cases of plug-ins. At least, I don't
feel it is for these particular use cases.
Also getting rid of gimp_action_get_proxies() API which is now unneeded, I
think. Furthermore GimpMenu does not have to connect to label changes. Making
the items proxies of a GimpAction is enough to have them updated.
The tooltip contains the reason for action inactivity, if relevant. And in case
of a GtkMenuItem in particular, it will also contain the "Press F1 for more
help" text at the bottom.
Not sure why gtk_actionable_set_action_name() works fine to activate base
GimpActionImpl, but not subclasses like GimpProcedureAction or GimpEnumAction
(and maybe others subclasses?), such as the "file-open-recent-*" actions. This
will have to be investigated further IMO.
While in the menu, under a contextual "Open Recent" submenu, it is well
understandable, the action is much less understandable without context, e.g. in
the action search. So I prepend an "Open" prefix.
Maybe a future alternative could be to have GimpAction have both contextual and
non-contextual labels (a.k.a. short vs long label)?
The proxy properly shows a color area or viewable (depending on context), and
this is properly updated when the associated properties are changed.
The label change is also properly updated in the label part of the proxy.
Very relevant actions to test the proxy items are dynamically updated are
generated actions such as the "file-open-recent-*" actions (with both label and
viewable updates), or again the Edit > "Fill with (FG|BG Color)|Pattern" (with
color/pattern updates).
These are the menu items such as the recently opened images, or recently used
filters, etc.
Some notes:
- I added back a "placeholder" concept in the GimpMenu logic. This will allow to
place items at specific positions in the menu (either under the placeholder,
which will make the last item be on top or above the placeholder to have the
last item be in the bottom, depending on needs). Technically placeholders are
just menu items with a label (used as placeholder key) and no associated
action, which I will leave invisible.
- I add a logic for submenus so that they are invisible by default and are only
made visible when we add a menu item with an action in there.
- I removed filling the "/Filters/Recently Used/Plug-ins" placeholder. As far as
I could see, it was never filled (neither with old or new code) and the
"/Filters/Recently Used/Filters" actually already takes care of filling the
"Recently Used" submenu with both GEGL operations and plug-in calls.
- The old gimp_ui_manager_add_ui() API is for all types of menus, e.g. including
the ones created by dockables or elsewhere whereas my new API is (for now)
still specific to the top menu. This will have to be further implemented
later. I left a bunch of "TODO GMenu"-s for the time being.
- I see 2 dock-related generated items which seem to never be added, for
recently added and closed docks. It doesn't seem to work in the old API as
well. I'll want to have a closer look too.
Some actions in particular can change their label. E.g. "file-export" and
"file-overwrite" will have customized labels containing the imported or exported
file name. The menu will now reflect such changes, live.
I'm starting to override GtkAction properties, starting with "sensitive" in
order to finally move away from GtkAction. Obviously, this breaks the
sensitivity check of the original menu.
I could reproduce this while closing GIMP immediately after starting it.
Sometimes the idle source would be running and working on now finalized objects.
"windows-show-tabs" and "windows-use-single-window-mode" were set to FALSE by
default, while it is now supposed to be TRUE, same as the config properties. The
discrepancy was only showing with my new GimpMenu which better follows the
action's state.
This demonstrates a first version of our replacing menu, using GAction and
GMenuModel. I had to make our own subclass of GtkMenu to process the model (from
a .ui XML file) for the following reasons:
* gtk_menu_new_from_model() doesn't support tooltips, which is a feature we use
quite extensively in GIMP: with all our filters, being able to give a longer
description is often useful; moreover we use tooltips to give hints about why
a menu item is deactivated as well.
Unfortunately it looks like GTK doesn't consider this lack as a problem and
don't plan on adding tooltip support.
See: https://gitlab.gnome.org/GNOME/gtk/-/issues/785
* I won't to avoid copying action's label and icons in the .ui file. This only
duplicates strings and would be a source of issues each time we change
action's strings (we'd have to do it in 2 places, which someone will
inevitably forget).
Now it still has various issues:
* The syncing between actions and menu items need to be cleaned up. It's still
in early demo code.
* It uses directly some Gtk*Action code because GimpRadioAction and
GimpToggleAction are not directly related right now (only through their
parents).
* gtk_application_set_menubar() might still be necessary on macOS as I think
it's what enables the native menu system on this OS. It means that we'll have
to edit the menu model to add back the labels (as this function does not
extract these from the linked action since GAction has no label or icon
concept).
* Icons are not taken into account right now.
* I'll have to verify if GimpAction with proxy work (but my guess is that right
now, it won't).
* Action's active state is not synced with menu item active state right now.
* Various actions are inserted live, such as opened images, opened views,
recently opened images, and so on. This needs to be implemented back.
* Plug-ins need to be able to create their own menu item into this new menu.
* For all these various reasons, I'm keeping the old menu around, for the sake
of comparison, until the time the new one becomes feature-full.
Part of this commit is inspired by !558 and obsoletes this MR.
Simply with a NULL context, we can't set or get accels from a GimpAction. Having
a mandatory context was a problem for GimpColorButton which could create a
GimpAction even though libgimpwidget has no knowledge of GimpContext.
All the remaining pieces of code where the deprecated concept of accelerator
closure was still used have now been replaced by proper GimpAction API using the
newer GAction API.
It's still not perfect, especially as we might want to get back GimpActionGroup
for this specific dialog (it may be nicer than an overlong list of actions). And
overall, I am not fond of this interface so maybe I'll want to review how we
display and change actions too. Moreover we now have the ability to set several
shortcuts per action, which was a really wanted feature and this dialog doesn't
allow this yet.
I'll get back later at this widget, but for now, it is a step forward for
deprecation.
- New gimp_action_get_display_accels() added to GimpAction API to get directly
the human-visible strings for actions.
- Also adding an "accels-changed" signal to GimpAction. As far as I can see,
even though accelerators are now to be set on the GtkApplication, there seems
to be no signals or properties to connect to at all on this class. So instead,
let's do it on our GimpAction (which means we must absolutely not use
gtk_application_set_accels_for_action()).
- GimpAccelLabel now uses the proper GimpAction API instead of accelerator
closure which is a disappearing concept.
In particular, there is no concept of accel closure for actions anymore in
GAction, which means that eventually gimp_action_get_accel_closure() will have
to disappear too.
Depending on the OS, the display name may contain characters which are not valid
for action names. In particular, on X11, the display name could be ":0.0" and
therefore we get actions named "app.dock-move-to-screen-:0.0" or
"app.view-move-to-screen-:0.0". The ':' is invalid, which will make calling
gtk_application_get_accels_for_action() (or more simply our new function
gimp_action_get_accels()) fail.
See docs of g_action_parse_detailed_name().
The new utils function gimp_make_valid_action_name() will help us get rid of
invalid characters for actions whose name was generated from strings we don't
totally control.
Furthermore gdk_screen_make_display_name() is now deprecated API, and more
generally gdk_display_get_n_screens() is deprecated too and now always returns 1
since GTK+ 3.10 (i.e. now each display only contains a single screen). Instead
we just use gdk_display_get_default_screen() for every GdkDisplay. So this
commit doubles as GTK/GDK deprecation cleanup.
If we want to reuse this in subclasses, we'd need to overwrite finalize() in the
subclasses, call gimp_core_app_finalize() and chain up with the parent class.
Not doing this until now was leading us not to call GApplication or
GtkApplication finalize() function, which in turn, in the later case, was
leaking all the GAction-s which were added to the GActionMap. I realized this as
a leaking GimpContext-s warning was printing when ending GIMP.
Adding a 'Show" before the image identifier, which is now between quotes, and
making this string localizable.
This makes the action more understandable, especially when listed in
less-contextual UI such as the action search.
The obvious reason why it was not implemeted in GimpAction is because as
interface, it cannot have a private struct.
Yet actually we can, by setting the struct as qdata on the object, as we do in
several other interface. This allows to move implementation of functions or
properties for things which make no sense to reimplement each time we implement
a subclass.
… "Add La_yer Masks with Last Values".
Add the "with Last Values", otherwise the shown label is the same as
"layers-mask-add" action, which is confusing (until we read the longer
description/tooltip).
It's basically a conveniency action for internal usage, which is similar to
"layers-mask-add" (except for sensitivity rules). In particular, I don't want to
see 2 seemingly identical actions in the action search.
There were 2 pieces of code where I was unsure of the use. I left them
surrounded by `#if 0` macros and a comment for the time being, to easily find
them later if we encounter issues.
Note that I could edit the GimpUiManager directly to use the GAction API, but I
feel like it is adding a level of complexity to existing GIO/GTK API. So right
now, I am planning to either get rid of it or really simplifying it a lot.
We had this feature "can-change-accels" where people could change their shortcut
directly by browsing the menu. It was on the property "gtk-can-change-accels" in
GtkSettings. Unfortunately this got deprecated in GTK+ 3.10 (more accurately in
dev version 3.9.8, according to GTK's NEWS file), and is therefore ignored since
then. In other words, whether we check the box or not in our Preferences, it
doesn't do a difference.
If we want to get the feature back some day, we'll have to reimplement it with
custom code. In the meantime, there is no need to leave this visible in
Preferences.
Right now, our actions are added both in the GActionMap (a.k.a. as
GApplication|GtkApplication) and with the old GtkActionGroup API. The later code
is meant to be removed soon.
A major difference with the old implementation is that we don't add the actions
in separate action groups. Even though GLib has a GActionGroup concept, these
don't seem to be used at all when adding actions on the GtkApplication level.
It might mean that eventually we will even remove the GimpActionGroup code and
move everything up one level.
Of course, I am still evaluating if we really want an action group concept, in
which case, we could simply recreate it, but I'm actually unsure how useful it
is. The only place where I see a use to this is in the shortcut settings (to
organize actions by groups), but even there, it was rarely useful to me. I
usually rather search for actions by text search anyway.
Since these were not children of GimpActionImpl, I had to reimplement basically
the same code, which is kinda ugly. When we'll have finally gotten rid of any
dependency to Gtk*Action, these 2 classes should be re-parented under
GimpActionImpl, hence simplifying their code.
A good chunk of the code is taken from GSimpleAction implementation in GLib.
Thanks to Lukas Oberhuber for his early attempt to implement something similar.
- gimp_image_add_sample_point: guide is a left-over from copy-pasting and
add apostrophe
- gimp_image_get_sample_point_position: it was not clear that the
parameter was the y-offset and the return value the x-offset
I noticed after porting the last few plug-ins that GimpPreview went
to black when you unchecked the auto-preview option.
These widgets must be added directly to the dialogue rather than via the
new API in order for the unfiltered image drawable to be loaded
properly. They will eventually be removed in favor of on-canvas preview,
but let's get them working correctly for now.
The warning was:
> Warning: GimpUi: gimp_procedure_dialog_fill_scrolled_window: unknown parameter 'contents_id' in documentation comment, should be 'property'
I realize that UI_TEST is only used in our meson scripts and is therefore not a
reliable environment variable to check for whether we are running a unit test or
not. GIMP_TESTING_ABS_TOP_SRCDIR should be present for all unit testing, on both
build systems.
- Lua, Javascript and Python were boolean defaulting to true, which was
installing them even when not available (and if not installed then, it
would show warnings at each run). Instead I make them features with
'auto' as default. In this default, we don't install when the
interpreters are absent.
- These 3 options can still be forced by setting them to 'enabled' (the
interpreters are not actually necessary during build).
- Vala behavior stay the same (and unlike other binding, you cannot
force it since it has a build step); it's only renamed to just "vala"
for consistency of option naming.
The real problem was not actuall logout-inhibition, but availability of the
GtkApplication. Anyway this feature is not really to block the system while
unit-testing but for saving people's actual work. Let's just disable running it
in test case.
This will fix the CI.
Two of our scripts have a spinbutton step size the same as the page size.
Since page size should be larger than the step size, this causes a
CRITICAL in LibGimpWidgets:
gimp_label_spin_set_increments: assertion 'step < page' failed
We fix this by setting a page size larger than step size in
coffee.scm and tileblur.scm.
If a 1 bit PCX image is opened interactively, a dialogue will let
users choose to either use the built-in palette, or force the colors to
be black/white only. Otherwise, the user can choose this via a script
parameter.
The meson build had the tools tests disabled unlike the autotools build.
Since enabling them doesn't cause any problems, let's enable them for
meson too.
Our CI meson tests for single window failed even though the sessionrc
looked the same as the one created by the autotools tests.
Looking at the Makefile.am it explicitly states that the tests shouldn't
be run in parallel or in a different order than specified, which was not
the case in our meson build.
We change this by setting is_parallel to false for each build, and
setting a different priority for each test. Since higher priority values
execute first we count down.
I noticed that in our CI meson job certain tests were skipped, which didn't
happen with autotools.
On examination I noticed these tests check for HAVE_XVFB_RUN. Even though
meson checks for xvfb-run etc, it doesn't set HAVE_XVFB_RUN.
Adding HAVE_XVFB_RUN allows the tests to run without skipping certain parts.
Users have noted that legacy layer modes have better compatibility
when exporting PSDs and reopening them in Photoshop.
This patch adds a notice with that information to the PSD export GUI.
- Use a pre-defined MAXDATABLOCKSIZE for all the buffers filled with
GetDataBlock that is known to be large enough.
- When reading comments ensure that it always ends with a NULL.
- Ensure that the right/bottom frame dimensions are also within range.
Inspired by issue #9195 I went over how we handled error messages when
loading GIF images.
- I replaced some cases with g_set_error and added an error parameter to
ReadImage.
- Introduced function read_error that uses g_set_error when image == NULL,
or else g_message.
- Enabled translations for the messages.
- Synchronized the error messages used to reduce the amount of work for
translators.
- Changed the error code returned internally in a few places, to be better
able to distinguish between encountering and end_code (-2) and possible
corruption errors (-1).
- Moved allocating dest down to not need freeing it in case of error.
- Allow to show partial results in case of errors.
The IART and INAM metadata fields were stored in gchar arrays,
which have a limit of G_MAXSHORT indexes.
However, you can have strings larger than that in the format.
To prevent overflows, they were changed to gchar*. f_read ()'s result
is also checked, and an error is set if it returns 0.
The frame count variable is also now reset per icon block to prevent
overflow as well.
I'm actually syncing with a branch which I can't test right now because flathub
seem to have some breakage. For the nightly, let's just directly push as anyway
we can't test in Gitlab MRs either because of the non-master jobs timeout.
See: https://github.com/flathub/org.gimp.GIMP/pull/202
We should always keep the diff between these files to a minimum.
- Fix the markdown styling.
- Add commands on how to build GIMP from the local repository instead of a brand
new clone (otherwise I don't see how one could develop with flatpak). I knew
it were possible, but until today, I never tried to do this so I had to test
first.
- The cron file was from the very early flatpak experiments before Flathub came
into the picture, as well as the GNOME Nightly repository. Back then, we
wanted to set up our own nightlies or release repository through a cron.
- It is still interesting to keep some instructions for local builds of the
flatpak as some people want to use this for development (but all the part
about exporting to a repository, signing, etc. is now unneeded for such use
case). So I'm updating the howto to more current recommendations.
- `flatpak-howto.txt` renamed to `README.md`.
I am adding this note as a consequence of this discussion on Pixls.us:
https://discuss.pixls.us/t/gimp-patterns-and-the-gpl-license/35969
Now we were always very clear that GIMP can be used for whatever use you want
and that the project doesn't intent to claim any rights on produced artworks.
There is even a FAQ entry about the fact we don't intend to put any restriction
on people's work (though this FAQ entry was added in 2015 AFAICS):
https://www.gimp.org/docs/userfaq.html#can-i-use-gimp-commercially
Yet it's better to be as clear as possible. Therefore this new note in the
LICENSE file will serve to make sure any new data is properly licensed CC0 by
the simple fact of contributing it.
This is similar to the fact that people contributing patches to core GIMP (app/)
are implicitly licensing it as GPL. Now people contributing data to data/ are
implicitly licensing it as CC0 as per our LICENSE file.
This ports the main dialogue to use GimpProcedureConfig.
It also adds the GUI-only options to the procedure itself, so that you
can call them via scripts.
Additionally, the layer warning was fixed and
mnemonics were added to the
property titles.
@Wormnest notified me of issues with CMYK profiles overwriting existing
ones, and potentially access a dereferenced profile.
This patch adds an additional condition check, and clears out the
profile in addition to dereferencing it.
This adds "https://" as a valid website prefix in the ImageMap URL edit
field, in addition to http://.
It also restores the prefix change that 2.10 had when you switched URL
types. It also fixes code formatting in affected areas.
...no image is active.
There are Arbitrary Rotation options under both the Image and Layer
menus. All of those rotation options are disabled without an image open.
To keep consistency, this disables those menu options as well.
The Tools menu Rotation option is left as-is.
Adds a new PSDSupport struct to keep track of what unsupported features
a PSD contains.
It is then used to conditionally display a compatibility notice
via a GUI.
GIMP expects CSS palettes to end with a ";" when importing. However,
GIMP exports CSS lines without ";". This means GIMP can't reopen its
own exported CSS palettes.
The ";" was removed from the regex since CSS2 does not require
the last line to end with a ";". However, CSS3 and above
require ending all lines with a ";", so it is added to the
export script.
When porting IFS-Compose and GFig to GAction, I originally created
all icons as GtkToolButtons. However, the toggle buttons no longer
appeared "pressed in" when selected.
This is fixed by creating those as GtkToggleToolButtons instead.
A lingering UIManager object was removed from IFS Compose as well.
See #9136.
(cherry picked from commit 0cd38a87e1)
Note: when cherry-picking, the tags were fixed as the main dev branch does not
need the underlined tags for localization anymore.
The initial issue was that 3 leaks were detected when running the "DumpCompiler"
during g-ir-scanner phase. The failing command was apparently about running some
temp binary, which looks like would be called the DumpCompiler in g-ir-scanner
code:
> libgimp/tmp-introspectn8jg64to/Gimp-3.0 --introspect-dump=libgimp/tmp-introspectn8jg64to/functions.txt,libgimp/tmp-introspectn8jg64to/dump.xml
My first fix attempt was to try and play with build/link FLAGS so that this temp
binary is built without sanitizer. But the problem when I did this was that
libgimp itself is sanitized, so we are mixing a sanitized lib with a
non-sanitized binary:
> ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
So it looks like I could still solve this with tweaking LD_PRELOAD, cf. this
sanitizer FAQ: https://github.com/google/sanitizers/wiki/AddressSanitizer#faq
Nevertheless it proved complex to do it right while not interfering with other
parts of the build and I found out that I risk encountering more issues down the
road with GIR + sanitizer:
https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/375
So I've decided that I didn't want to waste too much time on this and simply
disable introspection when sanitizing, as I guess what we care the most to
diagnose when sanitizing is core code anyway.
Especially as our code does not actually leak as far as we can see. It looks
like librsvg might not play well with -fsanitize=address (possibly having real
leaks or false positives).
gimp_display_shell_render() writes to a GeglBuffer backed by allocated memory
(shell->profile_data). Unfortunately while converting prevision in
gimp_image_convert_precision(), we change the "precision" property (hence the
source format) first, hence end up trying to write data in a too small buffer.
This crash was hard to find as it was not showing up on my machine (though it
did produce rendering artifacts!), unless I built both GIMP and babl with
`b_sanitize=address`.
Note that an alternate fix was to make sure that the profile_data buffer is big
enough (by calling gimp_display_shell_profile_update() before rendering), but
anyway the image is in an inconsistent state while conversion is in progress:
whereas the `src_format` is the new one, the `src_profile` is still the old one
(and cannot be changed before we finish converting).
Moreover the render happen regularly on progress signals, once after each
converted drawable. So each of these rendering step happens in an inconsistent
state, with the wrong profile set, some of the drawables converted and others
not yet.
We could still render properly if each drawable's buffer used space-aware format
(thus allowing different drawables to use different profiles/spaces), but it
feels over-engineering the problem. It might be much better to ignore rendering
steps while converting the image precision. Moreover it would obviously make a
faster conversion.
See discussions in #9136 for this crash, which didn't have dedicated report
AFAIK.
(cherry picked from commit de25be9210)
Note: on the `master` branch, even with sanitized code, I don't get the crash.
Yet this change seems relevant enough that I'm adding it.
In case of negative y in the region to process, we were accessing invalid memory
(negative array index).
I hesitated between make so that a given ordinate always use the same index or
if we just want the start ordinate (whatever it is) to use index 0. The later
could have just been `(y - result->y) % RANDOM_TABLE_SIZE`.
I just decided to keep the existing logic (former case) though to be fair, not
sure it matters much.
(cherry picked from commit a86560bb57)
Cf. the previous commit: colorsvg2png has a memory leak in librsvg (so we can't
fix it easily). In any case, it's just a one-time-use tool, we don't really need
to focus on its memory bugs as long as it does its job to make icons.
Actually even with this, b_sanitize=address still detects a memory leak. After
some testing, it seems that just creating a RsvgHandle, then freeing it
immediately is enough to leak some data, which means the leak is in librsvg.
Additionally, the ImageMap-specific icons weren't showing up due to the
filenames not matching the references strings ("imap-polygon" but
the filename was "imagemap-polygon.png"). This patch fixes that by
renaming the strings to match file name.
Partial code style fixes were made as well; a lot more are needed.
The magics used for detection for CUR and ICO are not very unique and
interfere with the detection of certain types of TGA images.
Since these TGA images are regularly used, it seems better to only base
CUR and ICO detection on the extension, just as we do with TGA version 1
files.
See also issue #7912
Krita had a bug where it incorrectly saved 4 for the alpha bits instead of
8. We will allow 4 and convert that to 8 to be able to read the incorrect
TGA images.
The likelyhood of real TGA images with 4 alphabits seems pretty low, so it
should not interfere with real images that have this set. We were not
supporting that anyway.
- fix a typo s/Commponent/Component/.
- Add &std_pdb_compat() to the new PDB procedures (I realize that's probably
what the contributor was asking about, back in !446). Not sure if it's right
as there were none in this file, but these are clearly just wrappers around
GEGL ops, so it seems fitting.
- Some alignment fixes.
- More accurate "$since" variables.
(cherry picked from commit 66ef1ef1ef)
(cherry picked from commit dbf9f277a2)
Committer's (Jehan) updates:
- Component type is now int32 (int8 is not a PDB type available anymore).
- PDB files re-generated to handle changes in API and types.
When a plug-in enters a bogus file name such as "Untitled.xcd" as URI,
g_file_is_native() returns FALSE. So when saving such file, core code tries to
mount a remote volume and fails (of course), without even opening the file
dialog.
This change is an attempt to detect such cases beforehand and not even try to
save it (just open the file dialog directly; the file name is still useful as
default proposed file name, as this part is actually valid).
Actually remote files will have a valid URI anyway (something with a valid
scheme, such as https:// or whatever other scheme).
As side fix, I am adding a missing space to the error which I got.
- This is unneeded in all import procedures. See previous commit. Note though
that this is not because of a change in previous commit. This was already
useless previously. The file set with this PDB function was overridden by the
core anyway (i.e. even before the previous commits).
In app/file/file-import.c:file_import_image(), the imported file is correctly
set (so there is no need to set it from plug-in, which anyway libgimp's
gimp_image_set_file() was not doing) and the XCF file is reset to NULL
(rendering the call to gimp_image_set_file() in a GimpLoadProcedure useless).
- Similarly, this is a useless call in export procedures because
app/file/file-save.c:file_save() overrides such call too. I could only see one
such case for JPEG export, which was quite useless.
- Finally in other types of plug-ins, setting a non-XCF file extension was
interfering with the save feature (similarly to commit e6e73e14c7). I only
fixed the screenshot implementations doing such a thing.
- I left a few usages which will have to be looked at more in details later.
This is not made to set the imported or exported file, but only the XCF file.
See previous commit to see what happens when this API is used to set non-XCF
file extensions (saving fails unless one edits the filename).
This commit is a fixup commit for MR !790 which had a few issues:
- The args for shadows and highlights adjustments are "shadows-ccorrect" and
"highlights-ccorrect" respectively.
- Also fixing generated code.
(cherry picked from commit e456ab019b)
This code is taken from Massimo's comment in #1786 and MR !834. It doesn't fix
a crash as this was already handled in !404, yet the missing prompt after
hitting "clear" was clearly not consistent with how one expect a clear feature
to work.
At least now, we've got a prompt back immediately after clearing.
Some PDF have transparency on purpose. Filling with white, without any question,
is counter-productive and prevents from working on such PDF files.
Note that we could add an option with a checkbox, leaving one to decide whether
to fill the background or not. But it feels over-engineering the issue. The PDF
is transparent, so that's what we load, and that's it. If one wants to add a
background, it's easy to add a layer at the bottom of the stack (and they can
make it any color they want, not just white), after loading the file.
I had a TIFF file which would crash while triggering an error, inside g_logv()
code (and according to the stacktrace, even probably inside some lower level
printf implementation code).
The reason was that I already processed the variable list with
g_strdup_vprintf() and printf didn't like this va_list being reused, then
segfaulted with some "Cannot access memory at address" error.
The alternate fix was to first copy the va_list in the first use with
va_copy()/G_VA_COPY, yet since we already processed the format data, I thought
it was useless to do this. Let's just directly use the formatted string.
Apparently GDK/Win32 sends the "grab-broken-event" signal before the "clicked"
signal. This has only been changed since GTK4 so far.
Anyway the bottom line is that GimpContainerPopup would process a handled on
"clicked", using the object destroyed when "grab-broken-event" happened as
callback data. The solution is to make sure that the object stays alive long
enough. So I'm changing gimp_editor_add_button() to connect to signals with
g_signal_connect_object() (since all usage of this function was used with
GObject callback data, it was not a problem).
See discussion in !815.
As a side change, gimp_container_popup_dialog_clicked() should emit the
"cancel", not "confirm". This part was taken from MR !815 by Lloyd Konneker.
is positive or zero. Sometimes the calculated `y` or `bg_y`
values are negative because the histogram value was divided
by zero (when max == 0.0).
Resolves: #9132 (Gnome/GIMP bug tracker)
Exports the following PAM formats:
GRAYSCALE, GRAYSCALE_ALPHA, RGB, RGB_ALPHA.
As with import, the main difference is the header and transparency.
Raw PPM export code is reused for the actual data.
PAM files are essentially PPM files with a different header format and
alpha/16 bit support.
Jörg Walter's 2.2 code was updated and implemented to read the revised
header format. The existing PPM loading code works with PAM files.
Largely inspired by commit dddb23c6. This also gave me a good overview of the
various missing features in GAction (compared to GtkAction) and how we'll have
to implement this in GIMP core. I now have a very clear path of what remains to
be done.
… don't include it from public gimpui.h.
As reviewed during !786, if this file is private, the name should show it
clearly. And of course, we must not include it from another public header, since
it won't be installed.
This also fixes building plug-ins with gimptool as reported by tmanni:
e00f2d7f50 (note_1650791)
Nothing was really clearly specified until now, which was kinda equivalent to
the string being in the OS encoding as used by GLib. Since this string will
usually be statically hardcoded in code (and not extracted from system), it's
just much easier to request UTF-8 for this specific case.
As per the changes in commit 005b3a05b8 and discussions in !800,
gimp_locale_directory() returns a string in the OS encoding for all but Windows
(UTF-8), i.e. the "filename" type in GIR annotations.
It relied on the now non-existing max-rgb plug-in, which was removed in commit
dd89f4a3d5. After some thoughts and discussions, the Predator script is fun, but
clearly not a mandatorily "needed" one here, which is why — instead of
re-integrating max-rgb —, I have decided to also remove Predator.
Both these script/plug-in are not totally dead. They were moved to the
gimp-data-extras repository and even ported to GIMP 3.0 API. They can be an
interesting use case for a fun extension to be installable through our future
extension platform. To be continued.
Rename "Crop to Selection" to "Resize Layers to Selection" since it's not
necessarily a crop. The layer dimension can also grow now.
Also specifying "Layers" because action titles can also be displayed
off-context, such as in the action search, so we must be more detailed with our
action titles. Similarly adding a "Layers" to "Crop to Content".
On Windows fopen () is limited to the current codepage,
GLib's g_fopen () instead accepts full UTF-8 by calling
_wfopen () internally (or a similar wide-char CRT routine).
We don't want to fail the build configuration just because we can't test for
runtime dependencies. In such a case, just assume it's good as we at least have
libheif and we can compile.
Fixes:
> ../meson.build:756:2: ERROR: Can not run test applications in this cross environment.
Even though, some format support might be missing, since codecs can be added at
runtime, it can always change later without having to touch GIMP. Yet we won't
be able to edit the desktop file when this happens.
See new comments in #9080.
Without this change, meson outputs this warning:
> meson.build:868: WARNING: add_languages is missing native:, assuming languages are wanted for both host and build
From libheif >= 1.14.0, the pkg-config variable will become bogus and always
return 'yes' so we now need to check for codec avaibility at compile time the
same way we look for these at runtime.
It may seem irrelevant to do these checks since these codecs can be added
anytime later, but it's still very good information for packagers to immediately
see that we have runtime package missing.
Do not call the undeclared exit function. Implicit function
declarations are likely not going to be supported by future compilers
by default, changing the outcome of this configure probe with
such compilers.
This plug-in has a partial GUI (a FileChooser dialog is launched).
However, you could only save the active gradient rather than choosing
any of them like the 2.10 version of this plug-in.
This patch ports the original UI so you can choose both the gradient
and file in interactive mode.
It's a test plug-in which doesn't actually need an image to work, so it's
annoying that it currently requires one (making testing more cumbersome).
Also cleaning up a bit the coding style.
Also make the start checks a bit more robust to broken core code by
double-checking that the palette is valid from the start, even though getting an
invalid palette should normally not happen anymore (at least I fixed one such
case with a palette with a NULL id in my previous commit; but it looks like our
core code is not perfectly robust and we should push the code to extensive
testing).
Note that the generated widget is currently ugly (no label and terrible UX), but
this is meant to improve soon.
When the core sends a NULL resource, which would be the default for object args,
hence is also what you get for the first call of a plug-in with a resource
parameter, libgimp was creating a GimpResource with NULL id, which is invalid.
It is much better to return NULL (since we made it so that NULL is a valid
value) and let the plug-in handle the NULL value as it sees fit for a given
parameter (they could just set the contextual resource for this type, or keep
NULL to mean "no resource selected").
This fixes failing to run plug-ins the first time (before any "last" values are
set). E.g. I had the issue when testing palette-sort.
Also I'm improving the error message when trying to use a non-installed resource
(it will now also print the resource ID and the error message). And the GError
was leaking in this case, so I properly free it now.
… moved to the implementation file.
When declaring with G_DECLARE_FINAL_TYPE(), the whole concept is that the struct
is made private (which also allows the type to evolve without breaking ABI if we
some day decide to make the class derivable). For this to make sense, the struct
goes in the implementation file, not the header.
For the rest, it's mostly alignment bugs and the like.
It is apparently how dependency names are supposed to be spelled to be taken
into account. The previous commits fixed some, but missed 2. I'm not sure they
will actually end up in the right-side list of the docs (it looks like when a
dependency is not actually found in the API, it isn't listed there), though it's
at least always listed in the left side, as I can see it.
And while I would prefer the upstream "display" name (i.e. GEGL and babl instead
of Gegl and Babl), better be consistent in how we list these dependencies in the
libgimp and libgimpui docs.
See discussion in !811.
Fixes:
> libgimp/gimpresourceselectbutton.c:510:9: error: a label can only be part of a statement and a declaration is not a statement
> 510 | GimpResource *specific_value;
As well as some coding style bug (space after '*').
This fixes the VAPI build. I am actually astonished the lib build seem to have
passed and that we didn't get double definition clashes.
The build error was:
[750/2424] Generating libgimp/gimp-ui-3.0.vapi with a custom command
FAILED: libgimp/gimp-ui-3.0.vapi
/usr/bin/vapigen --quiet --library=gimp-ui-3.0 --directory=/builds/GNOME/gimp/_build/libgimp --pkg=babl-0.1 --pkg=cairo-1.0 --pkg=gdk-pixbuf-2.0 --pkg=gegl-0.4 --pkg=gio-2.0 --pkg=glib-2.0 --pkg=gobject-2.0 --pkg=gtk+-3.0 --vapidir=/builds/GNOME/gimp/_build/libgimp --girdir=/builds/GNOME/gimp/_build/libgimp --pkg=gimp-3.0 --metadatadir=/builds/GNOME/gimp/libgimp /builds/GNOME/gimp/_build/libgimp/GimpUi-3.0.gir
GimpUi-3.0.gir:22111.7-22111.33: warning: Virtual method `GimpUi.ResourceSelectButton.draw_interior' conflicts with method of the same name
GimpUi-3.0.gir:26688.73-26688.73: error: The type name `ResourceSelectButtonClass' could not be found
GimpUi-3.0.gir:26695.73-26695.73: error: The type name `ResourceSelectButtonClass' could not be found
GimpUi-3.0.gir:26704.73-26704.73: error: The type name `ResourceSelectButtonClass' could not be found
GimpUi-3.0.gir:26712.73-26712.73: error: The type name `ResourceSelectButtonClass' could not be found
GimpUi-3.0.gir:26720.73-26720.73: error: The type name `ResourceSelectButtonClass' could not be found
Simplifies chooser widgets (e.g. GimpBrushSelect) by eliminating attributes (e.g. opacity) of chosen resource.
See #8745, but this commit fixes that by first refactoring the code.
Refactors GUI widgets (e.g. GimpBrushSelectButton and GimpBrushSelect etc.)
Refactor by "Extract class" GimpResourceSelectButton from GimpBrushSelectButton etc.
This moves common code into an inherited class (formerly called GimpSelectButton)
but the subclasses still exist.
The subclasses mainly just do drawing now.
Refactor by "Extract module" GimpResourceSelect from GimpBrushSelect etc.
Moves common code into one file, generic at runtime on type of GimpResource,
that is, the new code dispatches on type i.e. switch statements.
In the future, when core is changed some of that can be deleted.
The files gimpbrushselect.[c,h] etc. are deleted.
The module adapts the API from core to the API of callbacks to libgimp.
Note that core is running the resource chooser (select) widgets remotely.
Core is still calling back over the wire via PDB with more attributes
than necessary.
The new design gets the attributes from the resource themselves,
instead of receiving them from core callback.
The libgimp side adapts by discarding unneeded attributes.
In the future, core (running choosers for plugins) can be simplified also.
Fix gimp_prop_chooser_brush_new same as other resources.
Finish changes, and clean style.
Annotations
So procedures can declare args and GimpProcedureDialog show chooser
widgets
Fix so is no error dialog on id_is_valid for resources
Palette.pdb changes and testing
Memory mgt changes
Gradient pdb
Font and Pattern tests
Test brush, palette
Cleanup, remove generator
Rebase, edit docs, install test-dialog.py
Whitespace, and fix failed distcheck
Fix some clang-format, fix fail distcheck
Fix distcheck
Cleanup from review Jehan
It is better to add a comment rather than simply disabling these 2 calls without
explanation on macOS. This way, developers who'll look at this code in the
future will immediately know what's the reason and status for the "unicity"
concept of GIMP process on macOS. Basically there are 3 features:
- Opening files from another software (such as "open with" in file browsers)
which is handled differently in macOS and apparently works fine. It looks like
it works by handling system signals, connected from gui_unique_quartz_init().
- Opening files by running a new GIMP process which would pipe the filenames
into an existing GIMP process before immediately exiting.
- Running batch process in an existing GIMP process, also by running a short-run
GIMP process.
The last 2 features are simply now officially disabled in macOS because dbus is
not installed by default and seem like it may cause issues when it is.
See discussions in !808 and #8997.
DBus can cause instability on the MacOS platform, and regardless
MacOS handles application uniqueness already.
The batch version has also been modified as it only applies if
compiled as an application, since it returns FALSE if it is complied
as a console app.
These are not used anymore anywhere in our codebase! I'm sure some issues still
exist in various places, yet we can now consider that the multi-item awareness
project is finally over! Wouhou! 🥳
One big question which remains is whether I want to get back to the old naming
of "active" items, rather than "selected" items. The main reason to change the
wording globally was to be able to easily find remnants of non-multi-item aware
code. Now that it's all gone, I could very simply revert to the old naming.
This is in particular a big question for the public API for plug-ins, as the
"active" wording has been used for decades litterally. The only difference now
with how it used to be is that we could have several active items at once.
- Duplicate and Delete Paths are now both callable on several paths at once.
- Path Edit and Edit Attributes can only be run with exactly one path selected.
- Merge Visible Paths obviously always worked with more than one path.
- "Discard Text Information" work on all selected text layers.
- "Text to Path" creates as many paths as there are selected text layers.
- "Text along Path" still only works with exactly 1 text layer and 1 path
selected.
This is because gimp_drawable_edit_clear() would also clear the full drawable in
the special case when there is no selection at all. So as we were inverting the
"all" selection, we were ending up in this special-case.
RGB 0..255/0..100 and LCh/HSV settings are now remembered when closing
and reopening GIMP.
A few enums were explicitly cast to GimpColorSelectorChannel to clear
some compiler warnings.
This second GIMP_IS_ITEM() test was obviously for the iter2->data item. This
fixes handling cases when aligning/distributing a mix of GimpItem-s and guides.
I'm not sure if there are a lot of cases where we might want to use the layer
extents for items to align while using the contents extents for the reference
(or the other way around). It looks to me you either want one of the other for
all the items in the most common case.
So for now, let's apply this option to both the items to align and the reference
item. We'll see if anyone wants a separate option some day and has a good use
case to submit for this.
Trying to arranging both doesn't make sense and only end up in weird result. If
both the parent (layer group) and one or several child items are selected, just
arrange the parent.
This extends the work done in !778 to open the GEGL operation dialogue
automatically when selected from the menu, rather than requiring the
user to click on the canvas first.
Python 3.10 introduced sysconfig.get_default_scheme() and somehow Debian decided
it was a good idea to move from the 'posix_prefix' to the 'posix_local' scheme.
See: https://lists.debian.org/debian-python/2022/03/msg00039.html
The main issue with this scheme is that it adds a local/ subdirectory to the set
--prefix. As a consequence, with --prefix=~/.local/, scripts are installed in
~/.local/local/bin/ (instead of proper ~/.local/bin/), data are now in
~/.local/local/share/ and so on.
As expected, this broke a lot of CIs for a lot of projects, as well as a lot of
custom scripts, usage of Python in virtualenv (this later case seems like it is
fixed by special-casing it in Python 3.11), flatpak, etc.
Setting DEB_PYTHON_INSTALL_LAYOUT environment variable to "deb" solves this by
changing the default scheme.
This URL is also useful to understand the issue:
https://askubuntu.com/questions/1406304/virtualenv-installs-envs-into-local-bin-instead-of-bin
As a side note, Debian is not the only one which made the mistake. Fedora also
did the same thing (and they have also their own different environment variable
to handle this): https://bugzilla.redhat.com/show_bug.cgi?id=2026979
Adds import and export support for clipping paths in PSD files.
On import, path name and flatness value are saved in parasites.
Prior settings are loaded in the GUI on export.
Add a new type 'byte' to be able to handle binary data while still
retaining the utf8 char and string behavior.
Internally the file and string port and character handling have
been reworked to use the new byte-centric functions.
Also adds a new test script (test9) that tests byte, char and
utf8 string handling.
Only libgimpui depends on GTK+, display servers and other GUI-related
dependencies. There was a problematic include added in commit 0b56aa0d13 for
macOS, but the needed code (testing the macro GDK_WINDOWING_QUARTZ to use some
[NSApp activateIgnoringOtherApps:YES] API) doesn't seem to be present anymore in
there, so I think that removing this include (replace by including GLib for
other calls) should work fine. Of course, we'll know it when the separate CI
will test a macOS build as we still don't have in-Gitlab macOS jobs. :-/
This will allow to also check the list of runtime builds. We could see an
example in a report (#8993) where someone had the latest flatpak build of GIMP
but an older build of the runtime flatpak. So they had a bug because of a
dependency which got updated since then.
Add several missing help ids, remove those that are not used anymore,
and update "gimp-colorselector-water" to "gimp-colorselector-watercolor".
Also add a comment why some help ids are not used directly.
In the last few days, our deps-win64 job started to fail with:
> $ update-alternatives --set x86_64-w64-mingw32-g++ /usr/bin/x86_64-w64-mingw32-g++-posix
> update-alternatives: error: no alternatives for x86_64-w64-mingw32-g++
The reason lies in this change in Debian testing 10 days ago:
----
gcc-mingw-w64 (25) unstable; urgency=medium
* Upgrade to GCC 12. Closes: #1023679. It is no longer possible to tweak
the installation directory for different thread models, so the -posix
and -win32 packages are no longer co-installable.
* Drop “Built-Using” from “Architecture: all” packages.
* Since the POSIX and Win32 packages are no longer co-installable,
drop support for alternatives and use symlinks to provide the full
set of command names.
* Standards-Version 4.6.1, no change required.
-- Stephen Kitt <skitt@debian.org> Mon, 12 Dec 2022 09:00:34 +0100
----
So from now on, we'll only install the posix variant of the cross-compiler.
Hopefully it will work for all packages we build.
Adds option to export JPEG XL images in CMYK/A format.
Key and Alpha data is saved in extra channels, and the
simulation profile is saved as well.
Per the specification developers, the format does not
support 'naive' CMYK conversion, so a profile is required
for export. The option will be disabled if not set.
Checks if file has an extra key channel for CMYK. If so, it is combined
with the image's CMY image to create a CMYK buffer for import.
Color profile is stored as image simulation profile.
If alpha channel is present, it is now loaded as well for CMKYA images.
The URI will be: https://developer.gimp.org/core/maintainer/release/ (once we
merge the testing website to the main)
The new procedure also contains a wrapper step where we paste the checklist,
markdown-formatted, into a Gitlab report for better progress follow-up and also
onboarding testers into the release procedure.
The current code was wrong, hence was producing wrongly versioned shared
library files. This commit do it the same way as we do it on autotools build,
and additionally compute the library version (since "current:revision:age" gets
transformed into "(current - age).age.revision" by libtool, but meson doesn't
use libtool so we have to do this ourselves).
Now meson and autotools builds produce the same result at least. There are still
some points I'm wondering and which we should handle before GIMP 3.0 release:
* Since meson doesn't use libtool (and no .la files are created), should we
actually stick to libtool version scheme? It seems like some projects would
use semver instead. On the other hand libtool version gives a bit more info.
* Also it raises the question on whether we want the API version to be semver at
all or simply follow GIMP version? It used not to be much of a problem as we
wouldn't add features (hence new API) on micro version, yet now we can. So
GIMP program's version could not pass as semantic versioning. On the other
hand, having a diverging API version (whose minor version would increment
faster in particular, with regular micro version resets) would be confusing
too.
* If we keep libtool versioning, I'm thinking we should do it manually. It's
actually pretty easy with a good docs (or even just following GNU docs:
https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html),
and simple to understand whereas the current code logic is very weird and we
end up with huge current and age values with complicated computation.
Note also that I raise the "Libtool versioning" section near meson.build top and
updated gimp_interface_age to be the same as on autotools currently.
- The <_p> or <_li> syntax for localizing AppData is the old code logics from
intltool.
- Mailing lists don't exist anymore. Move all usage on discourse.
- Microsoft Store is only for stable builds.
- Let's always merge `origin/testing` into `master` on gimp-web module (no
cherry-picking) as it's clearly the procedure we've been doing for quite some
time now.
GtkTreeView has an "interactive search" feature built-in, which basically kicks
in with the Ctrl-F shortcut by default. Let's hijack this feature and trigger
our own new search popover which is much more powerful (multi-item selection,
ability to use regexp or glob search by enabling these in Preferences, etc.).
This was an idea by Aryeom who wanted to be able to hit Ctrl-F to search for
layers.
These are typically debug outputs and we don't want them to appear on stderr of
release builds. They confuse people (some tester would report these on IRC when
we last release GIMP 2.99.14).
So let's not show these debug text on release versions.
Only the libwmf patches are still different. Apparently we may have fixed the
same bugs in different way on both branches. We should look later in details to
see if some patches are better than the other.
This adds a check to make sure icon is valid when displaying
the icons in order, to prevent duplicates showing there and in the
invalid list at the bottom
It's probably unneeded as the 2.99 installers are transient and anything
installed by GIMP 2.99 won't be in stable 3.0 anymore. Still, it's nice not to
have any weird warnings even in dev releases.
This explains such WARNING over a previous installation on Windows:
> (gimp-2.99.exe:11524): GLib-GObject-WARNING **: 21:36:36.664: Two different plugins tried to register 'ControllerDXDInput'.
The previous install was autotools-built, so it didn't have the typo.
When the clipboard contains raw image data or single layers, it's the same as
the normal "Paste" (and "Paste In Place" respectively). These actions are useful
if you want to copy a bunch of layers and paste them "merged" into a single
layers (since now the copy-paste of multiple layers will create multiple
layers).
It is somehow similar to the "Copy Visible" action except that it works on
selected layers only and work at paste time, making the action more versatile.
There are so many paste options and I feel that the "Paste into Selection*"
actions are advanved enough that they can go into submenus. So I move them into
"Paste as". The other reason is that I'm going to add 2 more options!
I hesitated to rename the "Paste as" submenu but we couldn't find a good naming
(except just "Paste" but it's redundant with the default action and "Paste…" but
this usually implies a dialog, not a submenu).
Last but not least, I renamed the various paste actions to contain the word
"Paste" in it. E.g. s/New Image/Paste as New Image/. The old naming made sense
when action labels were only displayed in menus. But nowadays they can be shown
in other more independant context, such as the action search (and just
displaying "New Image" in there is very misleading).
When dropping a buffer, we just consider it like common data pasting, hence we
leave the GIMP_PASTE_TYPE_NEW_LAYER_OR_FLOATING algorithm decide what type of
paste it will be.
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.
After further discussions with Aryeom, we had to make decisions about a few
problems. The main problem was: what happens when we copy a selection of a layer
whose bounds don't intersect with the selection?
The silent treatment of discarding the layer was not acceptable, because e.g. it
could happen on huge set of selected layers (like say you copy 100 layers with a
selection: you expect 100 created layers and if you realize you don't have them
all — e.g. you have 99! — after hours of work, trying to find the missing one
can be a huge time loss).
The status bar notification (or even error) did not feel right either because
this can typically be missed easily. Also it doesn't give a lot of feedback
(e.g. you might want hint to find the non-intersecting layers, in case it was
not supposed to happen).
An error box was even considered, possibly proposing to ignore the problematic
layers, or even giving easy ways to find them.
Finally what if we let the selection happen regardless the non-intersecting
layers? What should the dimension and offset of said layers be?
In the end, we went with the more consistent behavior of always creating new
layers of the exact same size as the selection. It can be considered as a rule
which would make the behavior predictable. For the non-intersecting layers, we'd
just have new layers with the dimension/offset of the selection bounding box,
and no contents. For other layers, they'd be also this same dimension, possibly
increasing the dimension of the source layers (though any new pixel is fully
transparent obviously). Aryeom wondered if some people might absolutely need for
their workflow that the new layers stick to the origin bounding box. But we felt
it was enough of a stretch that we'd try this way for now.
Note: of course if some day we get infinite canvas/layers, this whole discussion
could be less of a problem anyway! This was Aryeom's conclusion! Ahahah!
This is also work-in-progress for better copy-paste handling for multi-items.
Until now, I had decided that, if a selection existed, a copy would copy a
merged version of the selected items. But sometimes you want to have a piece of
each layer, each piece in its own layer. Also you may always merge the pasted
layers afterwards.
So now we will indeed create as many layers out as there are layers in. Being
able to copy a merged down version of all selected layers is still an
interesting feature though. We might add a dedicated "Copy Merged" action,
similarly to the fact we have a "Copy Visible" (which does the same thing but
for all visible layers, not specifically the selected ones).
Position of pasted image data was getting very bad lately, especially with the
multi-item selection logic which confused the hell out of the legacy algorithm.
So I reviewed it a bit, in light of the multi-item abilities, as well as the
recent no-floating-selection paste changes.
One of the particularly wrong paste position was when pasting one or several
pieces (through selection) of existing layers. The positionning was really bad
and sometimes even off-canvas (which was explicitly forbidden by the algorithm,
except it was broken now).
Now the behavior is much more reliable and consistent, by centering on viewport
or on target drawables. If there are several such targets, their bounding box is
used as target position (and the bounding box of all source drawables is also
used now). An interesting consequence of this is that copy-pasting quickly
without removing a selection paste "in-place" since the target this time will
use the selection bounding box.
Aryeom and I are doing some work on specifying copy-paste (based on existing
logic, we tried not to disrupt too much years of logic, but also keeping
consistency and new logic for recent changes, such as multi-items). It will all
be written down into the GIMP developer website, section "Specifications".
When several drawables were selected, it was pasting at the top of the layer
stack. Instead, paste over the top selected layer ("top" visually in the Layers
dockable).
There was the question of: what should we do when pasting over a layer group.
Should we consistently paste the new layers above the group or inside the group?
After discussions with Aryeom, we decided to stay consistent and paste above, at
least for now.
This changes the default selection pasting behavior to be a new layer,
rather than a floating selection. It also removes the
"Paste as New Layer" submenu options as they are now redundant.
The histogram is still not multi-drawable aware. In the future, it would be nice
to add ability to generate histogram for all selected layers (merged and as
separate images) as well as the whole visible image, therefore 3 possible cases.
But for now, it's alright like this (no more, but no less feature than before)
and at least we got rid of the last usage of functions assuming single item
selection.
- Option dockable is named "Align and Distribute" rather than "Alignment".
First, because it's not just about alignment; also because this way, it looks
like other software, such as Inkscape; lastly because it's more consistent
with other tool options ("Move", "Rotate", etc.).
- Add a tooltip to the Anchor Point widget to explain what it's used for.
- Rewrite various align/distribute button tooltips to make clearer that we are
aligning anchor points with specific edges (or distributing these anchor
points).
- Rename the first section to simpler "Targets".
- Some more rewording of other texts.
It's clearly broken right now. I can see it might have been used even to
progressively shift aligned items, but this was not used anymore. As for being
used while distributing, it doesn't make any sense anymore with the new logic of
not moving the extreme (first/last in coordinates) items.
I can see how an additional concept of offset can be useful in some situations,
but for now, let's get rid of this. We'll see in the future if someone asks for
it and provides valid use cases to work from.
There was one case in Inkscape which we could not do: distributing objects
keeping even gaps between them. Until now, we could only distribute keeping even
distance between anchor points (top, left, bottom, right or center).
With these 2 additional distribute options, I believe that GIMP is able to do
all the Alignment and Distribution options available in Inkscape (not the
"Rearrange" or node features, neither the text align/distrib; I just mean the
common align/distribute on objects), and even a bit more thanks to the anchor
point system (e.g. in Inkscape, we can't left or right-align to a reference
object/image center, or we can't center to a reference left/right/bottom/top
border; but we can do it in GIMP).
The icons are hopefully temporary, until we can make better ones.
- Use g_malloc* functions instead of malloc, so we don't continue on
failed allocations unless we test for NULL.
- Make sure we don't iterate past the known number of control points (ncps).
- Safely allocate, initialize and free points. Since points seems to be
used uninitialized, we use g_malloc0 to set everything to 0.
After discussing with Aryeom, we decided that "Distribute" should work within
the current horizontal or vertical bounds, as this is how it is usually done in
other software (e.g. Inkscape). For instance, if there are 4 items, the first
and last (coordinate-wise) stay untouched, and only the 2 intermediate items get
distributed evenly.
Since the Reference is not relevant anymore for "Distribute", I undo part of my
previous commit, where I was organizing the reference setting into its own
section of the Alignment tool options. This setting is back as part of the
"Align" section.
- Adding a separate pivot widget to allow choosing which point of the items we
align or distribute. E.g. until now, we could only align the right side of
objects to the right side of the reference object, left to left and center to
center. Now these are independent. Therefore I can align the left side of
objects to the right border of a selection or a layer, and so on.
- Only keep 2 "distribute" buttons (for now). Most of the distribution actions
were basically broken or extremely hard to understand. Also they were
apparently mixing concepts of alignments with distributions. Now let's
basically only keep the bases: horizontal or vertical distributions.
Everything is still possible using a mix of alignment and distribution
buttons, and it's much clearer.
- Since the GimpAlignmentType was used nearly only there (except for some usage
like to store dock side or filter preview split direction, but these
GIMP_ARRANGE_* values were unused there), I removed the various enum values
which we don't use anymore.
- The Reference settings gets its own subsection in the Align tool options.
Until now, it looked like it only applied to alignment, whereas it applies to
distribution too.
Note: this is still work-in-progress, mostly some initial dev work to put some
algorithmic bases. We had some UI and specification discussions with Aryeom
already and some things might still change a lot.
There were various cases when the reference's on-canvas handles were not
redrawn, or drawn at all:
- When the reference is an image, we now draw them. It may seem redundant as
it's the image bounds, but it's still useful to see what are the reference
bounds in a glimpse. Moreover in "Show All" mode, it's even more useful.
- Start the tool, hence draw the reference handles, in oper_update() if not
started yet.
- When the "align-reference" property changes.
- When the display (active image) changes.
When the reference is a guide in particular, no distribution is possible (on one
dimension, the size is 0, on the other, it's infinite) and alignment is only
possible in one direction (depending on guide orientation).
I find these options always a bit unwise when people have no idea how to change
their mind. Therefore adding a tooltip with the information (though maybe we
should even do it even more clearly and adding that in checkbox text too?).
For this to happen, I've updated the main question to be "Keep the Embedded
Working Space?" instead of "Convert to * Working Space?". Basically now we put
emphasis on keeping the image's color profile as being the proposed action.
Therefore "Keep" is the default answer, on the right.
Yet "Convert" stays on the right too. There is no "Cancel" button anymore
because it is not a question we can really escape even though "Esc" still works,
and it still corresponds to "Keep", same as Enter now. The reason is that "Keep"
is actually the non-destructive option. So if someone really doesn't want to
answer and make an explicit choice, we do it for them with the only
non-destructive choice possible.
Also I'm changing "Convert" mnemonic to 'c'. I guess that earlier devs might
have used 'o' because it is the usual mnemonic for "OK", so it was right when
the question was "Convert?". But since now the question is the opposite, there
is no reason to make it look like "OK". Let's just use the first letter, which
is easier to guess (and not taken by any other button here).
I've been hesitating because I don't think "Convert" was the right default
anymore with our anyRGB move. Until now, it was kinda implying that sRGB (when
no preferred color profile was set) was kinda the recommended space. It's not.
If a file already has another space, it's probably much better to keep it.
First because "Convert" is often a destructive change (even more if the target
is sRGB), so for people who don't necessarily understand all the ins and outs,
we were kinda promoting a destructive default behavior.
On the other hand (and that's why I was hesitating):
* "Keep" is also what happens when we hit "Esc" so some might complain that
there is no easy "Convert" key anymore (there is alt-c, but it's for sure not
as easy as Esc or Enter). Basically it makes the "Convert" option always a
much more explicit choice (yet it is likely for the best for people who care
about their colors).
* There might have been many people who would just use the default (Convert
until now) without thinking too much of what was asked, and that was working
good because they would just publish on the web or similar basic usage. If
they continue just accepting with Enter without reading and understanding what
is asked, now they could publish images with a color profile (and we know it
doesn't always work perfectly on the web).
In other words, it might be the best default for professional usage now, yet
it requires to understand a bit what you are doing.
It's really a hard call!
Thanks to a report by Stefan Cornelius, we became aware that the flame
plug-in does no checking for correct input when loading a pre-saved
settings file.
I reworked the parser to read one or more values based on the type of
token, making sure we also don't read past the end of our token buffer.
All int values have a min and max value set. If any unexpected input is
encountered, we will give a warning.
The flame plug-in can read stored settings from a file. The expected
input is that a ; signifies the end of input.
However, with user input we cannot depend on this to be true, so we need
to make sure that we do not read past the end of our input buffer.
To do so, we add a length check.
We were using the plug-in name with underscores, which is incorrect.
Since nobody ever complained about this, this doesn't seem to be used
very often.
We will use the const that defines the plug-in name instead.
I added this option in commit 38d6783299. It makes the script stateful, able to
remember all previously processed DLL, hence making the whole job much faster
and efficient.
Adds a toggle to let users load TIFF pages with FILETYPE_REDUCEDIMAGE
tags. The specs do not state that these are always thumbnails, and they
may have other uses. We assume that if only one page with this metadata
exists then it is a thumbnail; otherwise, the toggle option is
enabled on load.
This was the last remaining bit in #8124. Basically I needed to check how
localization of menu paths worked. I was thinking of maybe have 2 arguments to
gimp_procedure_add_menu_path(), one non-localized (for default menu paths) and
one localized by the plug-in (for custom menus). That would break all plug-ins,
but also looking at our code, it's complicated to do right.
Instead let's just keep current API and add an example in function docs. We'll
see how we can improve the API if the very hypothetical problem I am foreseeing
actually happens some day: say a word in English translates to e.g. "Filters" in
some other language, whereas English "Filters" translates to yet another term;
in such case, this new menu would still merge with the default /Filters/ menu
when localized in this language, so we'd have the weird situation where the
custom menu label would have passed through 2 translations somehow.
But let's see how it goes. If we really need, in the future, we can deprecate
gimp_procedure_add_menu_path() and add a gimp_procedure_add_menu_paths() with a
base_path and a custom_path, while the custom_path would be expected to be
already translated.
Fixes:
> free(): double free detected in tcache 2
The file is closed also after resource_load() runs. Anyway it's better to free
resource on the same level they were created, so I remove the fclose inside the
function.
For the same file, which was saving in ~50 secs in RLE (now ~12), and ~80 secs
in zlib. It now saves zlib-encoded XCF in ~35 secs on the same machine with 8
threads.
Contributed code was not wrong, far from it! But the whole memory management was
a bit on the hard-to-read side. For maintainability, I prefer some simpler code,
which contains a bit more allocation but it's reasonable and at least much less
indexes to play with.
Also instead of gegl_parallel_distribute(), then waiting for each set of batches
to entirely finish, I'm using a GThreadPool which I progressively fill with new
batch data. And finally I'm running the gegl_buffer_get() inside the threads (I
know that we have only reads on the buffer at this point; also GEGL has an
internal lock mechanism anyway).
These actually do not provide a huge additional speedup (compared to the initial
speedup by just going multi-threaded), most likely because the I/O are now the
bottleneck anyway (which is quite a good thing!).
- Coding style fixes.
- Removing gimp_gegl_num_processors unknown variable which didn't exist (coming
from another patch from suzu. See discussion in #4985).
- Removing the `cleanup()` attribute to keep our code as generic as possible
without specific compiler extensions. Just free memory manually as is expected
in C.
Testing on a 115MiB XCF file, saving went down (on my machine, as average on
saving a few times) from about 50 seconds to 15 seconds.
This first version is already pretty neat, though we can probably do even
better.
This makes these buttons respond to scroll wheels again, a regression encountered in GIMP 2.99.x.
Code location and fix found by Massimo Valentini.
Fixes issue #6929.
Instead of storing vectors as properties, they have their own structure, which
make them able to store and load all the usual and common properties of other
items. In other words, it makes XCF now able to store locks, color tags and
several selected paths.
It seems I forgot to fix some usage of core gimp_vectors_export*(),
which now take a list of paths (not a single path anymore since commit
9fc8260c7c), as these were used by PDB functions.
Missing functions were:
* gimp_image_get_selected_channels()
* gimp_image_get_selected_vectors()
* gimp_image_list_selected_channels()
* gimp_image_list_selected_vectors()
* gimp_image_set_selected_channels()
* gimp_image_set_selected_vectors()
* gimp_image_take_selected_channels()
* gimp_image_take_selected_vectors()
There are discussions of renaming GimpVectors to GimpPath, which would
also be consistent with the GUI and make the always-plural less akward
in API. We'll see. For now keeping named like this.
We should not check if all items are locked, but if one item is locked. It is
enough to forbid the translation from happening.
Otherwise it is currently possible to bypass position lock by using keyboard
arrows for layers or channels.
The action "select-float" should probably only work for a single selected
drawable anyway since a floating selection can only be stacked on one drawable
at a time.
Actions "vectors-fill*" and "vectors-stroke*" require a single drawable to paint
to. So action logic is unchange. I only replace gimp_image_get_active_drawable()
by gimp_image_get_selected_drawables() and counting the drawables.
Instead of using the layer borders, we use the bounding box for the contents.
This is similar to first run "Crop to Content" on every selected layer except
we don't actually need to crop. Therefore we can work on bigger layer than the
actual content while still arranging them based on content bounds.
So often the result of alignment/distribution feels wrong because it doesn't
correspond to the content we are seeing. With this option, we'll have the option
to choose the desired behavior.
The old interaction was quite horrible. I don't think I ever really got a good
use of it. It was so hard to understand what you were picking and so on.
Now that we can multi-select items, let's just use this as the base of what we
want to align or distribute. Clicking on canvas will now mostly be used to pick
an item as reference. From now on, only the reference object will get on-canvas
handle, making it very obvious how your alignment or distribution will work.
I leave only an alternative picking method (with Alt or Shift-Alt pick) to add
guides to objects to align or distributes, as these don't have a selection
dockable.
I'm also improving the selection of stacked layers by looping through them
(similar as the layer selection on canvas feature) so that we can select even
background layers which have a lot of layers showing above.
I am planning to improve this tool even further, but this is a first step to
make it actually usable within the new multi-item interaction logic.
Even though GIMP updated the name of the define for Create Template to
GIMP_HELP_FILE_CREATE_TEMPLATE, it did not change the id string.
In gimp-help this string was updated, causing help not found when asking
for help for Create Template.
This commit updates the string used for the help id to be the same as
used in gimp-help. It also removes the old define that is not used
anymore in GIMP.
This help id was used in the past but all references to it were removed
long ago with commit c53113d0cc.
Let's remove this define too since it causes a warning in gimp-help when
checking for help id's without documentation.
Loading an .xcf with a patterned outline caused GIMP to crash.
This is because PROP_GIMP was loaded at the end, so it was null when
text->gimp->pattern_factory was called. Moving PROP_GIMP to the
top of the property enum list ensures it's loaded first,
which resolves the issue.
This ports Massimo’s code to work in the latest version of GIMP.
It adds new outline-related properties to GimpText and GimpTextOptions.
These are controlled via the Text Tool Editor.
Cairo is currently used to draw the outline around the text.
Just add a no-op flush() as I think it's actually unneeded in the context of a
GtkTextView GUI. At least it doesn't cause issues with copy-pasted code or when
using external libraries using the sys.stdout.flush() interface.
- Don't forget to run gimp_ui_init() to get GIMP's styling in plug-ins.
- Process the "key-press-event" signal so that Escape key closes the window (as
it used to before the MR commit).
- Expand vertically the tree view, otherwise resizing the window leaves a lot of
ugly empty space, even though the tree view is still shown incomplete with a
scrollbar.
- Fix the Help button (which was doing nothing).
- Use full words for the "Refresh" and "Help" buttons, rather than icons. Text
is usually prefered for UI discoverability/understandability, unless there is
a space issue (i.e. too many icons for all of them to be words).
- Add a "OK" button too, and reorder the buttons similarly to how we usually
order them.
- Minor coding style fixes (alignments…).
Just "help" is not one of the standard icon names as per the Freedesktop Icon
Naming specification.
See: https://specifications.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html
Therefore when using this name, we usually don't have any icon (especially as we
don't provide any in our own icon themes).
Use "system-help" instead which is a standard name 'for the “Help” system
category'.
There is not only the ARCHIVE_OK and ARCHIVE_FATAL cases. There are also
ARCHIVE_WARN cases which should not break the installation (I think?). Since I
still want to pass the warning over to extension developers, I am printing it to
stderr.
As an additional fix, prevent such a warning when installing an extension over
itself. In such case, it looks like the archive_entry_size() would be 0, which
was triggering some "Writing to Empty File" warning.
We may return GIMP_PDB_SUCCESS with no image for generic file procedure, such as
is the case with .gex extension files.
file_open_image() already sanitizes the status returned by the plug-in, so at
this point, we should trust the returned status.
This fixes a crash when loading .gex files (GIMP_PDB_SUCCESS status yet a NULL
error).
Automake doesn't accept the "if else" syntax. Instead, we must add a new if/else
inside the first else block.
While I'm at it, I also add a G_GNUC_INTERNAL to the internal function
_gimp_pick_button_win32_pick(), though I don't think it's absolutely necessary
(yet explicit is better).
- app_activate_callback() moved with other private functions.
- Removing the `if (app)` test in app_activate_callback() as we don't
set it to NULL anymore. The app variable is always set.
- As a consequence of the previous point, change signature of
app_exit_after_callback() which doesn't have to change the value of
app anymore.
- Don't emit direcly the "exit" signal from app_activate_callback(). We
must call `gimp_exit (gimp, TRUE);` instead, which does more than just
emitting this signal. It also takes care of cleaning any remaining
images without a display. If we don't do this, we are leaking
GeglBuffer when opening images from command lines while quitting
immediately with --quit.
- Get rid of gimp_core_app_set_values() which was completely bypassing
the fact that all the properties of a GimpCoreApp were construct-only.
Instead make these proper properties. I use a trick used in other
interface, creating a gimp_container_view_install_properties() which
is called from child classes.
The point of GimpCoreApp is not just to share a common interface, it's
rather to weakly simulate some kind of multi-inheritance in GObject.
Since we want both GimpApp and GimpConsoleApp to inherit from a same
parent class while we also want them to inherit either from
GtkApplication and GApplication respectively (yet without linking to
GTK in this second case), we are stuck as far as normal GObject
inheritance goes. This is why we use an interface to which we add a
private struct through a GQuark trick. We want the property settings
and function implementations to also be part of this shared code.
- Get rid of all the abstract methods of GimpCoreApp of the form
get_*(). These are useless as we don't expect these to have different
implementation depending on the actual child class. Once again, our
main goal was to simulate multiple inheritance rather than actually
have an interface with various implementations.
- Make "no-splash" a property of GimpApp, because it's cleaner this way.
- Fix gimp_core_app_private_finalize().
- don't use #pragma once, it's not standard. Just use include guards.
- Fix includes: order was wrong, include from the source, not other
headers, etc.
- Clean various other details, coding styles, fix several more bugs and
more…
Reviewer's message (Jehan): This was a work-in-progress by Niels, which
we only keep in this state because Lukas worked over it. I have rebased
and fix-amended many broken part of this commit, because various things
had been changed in these areas of code since this commit was initially
written.
.ani files require metadata fields to be an even length. If the data
length is odd, an extra 0x00 is added for padding.
This patch updates the export and import code to comply with this
requirement.
Now text layers are proper types, which means that the binding API will also be
nicer (e.g. `txt_layer.set_text('hello world')` in Python).
This commit also adds the param specs allowing to create plug-in procedures with
text layer parameters.
Finally it fixes the few calls in file-pdf-save (apparently the only plug-in
using specific text layer API right now) with explicit type conversion.
After re-reading #534, I realized I missed the discussion about unsupported
markup by the tool. Then I tested and confirmed what Ian Munsie initially said
in a comment: unsupported markups are properly rendered in the text layer, yet
are simply dropped when editing with the text tool.
This is actually the ideal behavior as it means that with the API, you can even
go further than what is currently possible with the GUI. So it gives nice powers
to people who can script GIMP. We still need some warning in the function
documentation to tell developers about this weakness in the tool GUI.
It seems I had forgotten some hardcoded color in there. I didn't notice it until
now, because it was not that bad in the few instances where it was shown (for
instance the comment field in export plug-ins), but I really realized there was
a problem with the Python console which was not too practical (white writing on
kinda light background).
This complements the existing text_layer_get_markup function and allows
scripts to create and modify complex text layers.
It adds the <markup> root tag if it was not supplied and will run the
markup through pango_parse_markup() to check for errors.
Reviewer's (Jehan) note: this is a mostly untouched patch contributed in #534,
except that code moved around. I also fixed the header set in the .pdb, a link
to pango markup docs and added the meson changes.
Fixes:
> /usr/bin/ld: ../libgimp/.libs/libgimpui-3.0.so: undefined reference to `gimp_check_custom_color2'
I am actually unsure this fix is fine. It doesn't look like it should
work. And worse, I can't reproduce the fix by reverting it after.
The only other person who reported it was akk, with exactly the same
symptoms.
I noticed some buttons had a bluish border, showing the system theme leaking
over our default theme. So I'm just overriding this with a grayscale color.
These 2 new rules are especially useful in dialogs so that you know what happens
when you hit "Enter". The "default" action (.suggested-action in GTK CSS) is the
action we set to be the active one by default. E.g. if you open a dialog and hit
Enter immediately, without touching any widget focus, this is what will be
activated.
The GTK CSS .default action on the other hand seems to simply be the button with
focus right now, which can be changed through Tab or other ways. If both types
of styles are visible, the .default one is the actually activated action (not
.suggested-action), which is why I make its style a bit stronger (solid rather
than dotted and a bit more opaque).
Also I discover the shade() function to reuse a color and adding it
transparency!
Checked buttons had a background using the @selected-color. This was because of
a too broad rule on `.text-button:checked`. Basically it looks like the broad
rules are not good because they sometimes override more accurate rules for
specific widgets.
I also make a few more rules a bit more accurate. Also I extend some CSS rules
for check and radio buttons.
Adds an option to export as CMYK (mutually exclusive with the existing
Duotone export option). Header information (mode and number of channels)
are set, and the data itself is converted via Babl.
Layer channels are also hardcoded to 4, since GIMP currently doesn't
support CMYK channels.
We had some concept of slightly more extreme theme colors (i.e. darker in dark
themes) to color differently in some widget-in-widget cases.
For instance, we use this in the treeview list to separate it better from nearby
interface. But this extreme dark background may have been a bit "too dark", as
reported by Jacob. The goal is for this list to stand out, but maybe it was
standing out too much. Hopefully it's better now.
As a side change, I also add some borders to the top icon header (with "eye" and
"lock" icons) just above the list. I think it better explain the separation.
Just use an inverted logic for the selected text (i.e. white on black in light
mode, or black on white in dark mode). This is the usual logic for rendering
selected text anyway (except that we don't use non-grayscale colors, e.g. blue
background is common in system themes).
As diagnosed in #8649, using a guint32 for windows identifier may have been
right long ago (was it?), but is definitely not anymore. I can see that a XID is
an unsigned long nowadays (usually 64-bit on 64-bit Linux).
As far as I can see, on Windows, it would be a void* behind (which also
corresponds to the error message in #8649 description):
> typedef void *PVOID;
> typedef PVOID HANDLE;
> typedef HANDLE HWND;
Cf. https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types
I *think* that pointers would be 64-bit on Windows 64-bit, though I'm unsure
(after all, this is an OS with 32-bit long int on 64-bit arch!).
Anyway, it's just better to move to 64-bit window identifiers.
Since Clang 15.0.0:
> The -Wint-conversion warning diagnostic for implicit int <-> pointer
> conversions now defaults to an error in all C language modes. It may be
> downgraded to a warning with -Wno-error=int-conversion, or disabled entirely
> with -Wno-int-conversion.
This kinda reverts commit 6aebd30de1 ("app: remove
icon sizing preferences"), except that the code base is different enough since
this old commit was mainly for GIMP 2.10.x.
In any case, after initially thinking that GTK+3 handling for high density
display would be enough, we finally decide that adding back a Preferences-wide
setting for overriding the theme-set icon size is a good idea (additionally to
GTK+3 automatic support).
The base idea for removing the feature was that GTK+3 has high density display
support, through the "scale factor". Typically a high density display will
normally be set as using a ×2 scale factor so all icons will be double size.
Unfortunately it turns out it's not enough.
For instance, on very small screen estate, even with a scale factor of 1, if the
theme sets 24px toolbox icons, it may still take too much space.
Oppositely on huge screens, even with ×2 factor scale detected by the OS, the
icons may still feel too small (this is possibly what happens with #7023).
Furthermore there is also a matter of taste. Some people like small icons even
when they have the space. Others may want bigger icons, easy to click on.
Finally you can like a theme for its color scheme for instance, but it may not
have the icon size you want. Right now, we'd need to duplicate every theme in
small or bigger size. Instead of doing so, let's just have this global setting
overriding the theme rules.
Comparison with the 2.10 implementation:
- We still provide 4 sizes: small, medium, large and huge.
- We don't have the "Guess ideal size" setting anymore. Instead this is now a
mix of the GTK+3 scale factor logic and the theme-set or custom size. I.e.
that on a high density display with ×2 scale factor, we could have toolbox
icons up to 96 pixels (48×2)!
- We now try to have less custom code in widgets as we append the CSS rules to
the theme (similar to what we were already doing for dark theme or icon
variants). What happens in widget code is mostly to connect to changes in
themes and redraw the widgets which need to be.
- The custom size will now affect: toolbox icons, the FG/BG editor widget (in
both the toolbox and the color dockable), dockable tab icons, the main
dockable buttons, eye and lock header icons in item tree views, eye and lock
cell icons in the item lists.
There are still a bunch of areas where it is not taken into account, such as
plug-ins, and various dialogs, but even in custom-made interface in dockables.
Ultimately it might be interesting to have a way to sync more buttons and
widgets to a global size settings.
Lastly, I fixed a bunch of existing bugs where we were updating icon sizes with
gtk_image_set_from_icon_name() using the const icon name taken from
gtk_image_get_icon_name(). As this was reusing the same string pointer, we were
ending with freeing the icon name.
This was massively breaking GtkScale rendering. Or at least the marks (and mark
texts) added by gtk_scale_add_mark() were simply invisible.
I tried to figure why, staring at the GTK inspector and testing various CSS
rules to fix it without removing this line, but just couldn't make sense of it.
In the end, I'll just remove this line. It looks like in CSS (or just GTK CSS?),
it might be better to set rules on accurate widgets rather than too broad rules. 🤷
This is the needed improvements I was talking about in commit 00fbcbea0b. Right
now, when changing the icon size, the FG/BG color widget was not immediately
resizing. It needed a restart of GIMP.
Now it will properly react to "style-updated" signal, but also to "theme"
property of GimpGuiConfig.
The reset of the color icon pixbufs is also needed when GimpFgBgEditor size is
re-allocated.
When changing the theme, the style-updated signal is *usually* run, but not
always. For instance, moving from a theme with big icons to one with smaller
icons (or the other way around) sometimes work, and sometimes doesn't. I'm not
sure if it's to be considered a bug in GTK or if this signal depends on other
things. Anyway we have our own "theme" signal on the GimpGuiConfig and we know
exactly that we need to make sure that the icons are properly redrawn in such a
case. So let's just connect to this signal.
So what we read on the topic is to use (as base color) the gray which is
perceptually half-way between black and white. Unfortunately it can mean
different colors. For instance if using the sRGB TRC, the #808080 color is
sometimes cited.
Instead I went with the color LCH (50, 0, 0), i.e. with half perceptual
lightness in "CIE LCH(ab) float" babl space, i.e. #777777 in sRGB. It
corresponds to the 18.42% gray which is often refered to, so it seemed a fine
choice.
This replaces proposal in !683 because the contributor is not responding
anymore, and also it uses the common theme base CSS files used by all other
official themes.
Write both ICC and NCLX boxes for RGB AVIF to make sure that
all browsers render the AVIF images in same manner.
Use heif_init/heif_deinit in libheif 1.13.0+
Something I wanted to implement for a long time and today I finally took
the time after I had one more annoying case where I had to merge all
groups for exporting then undo for saving!
Now this won't be needed anymore as the plug-in will allow to export
only as pages any first-level layers (groups included, so you could
gather your page compositions in root layer groups). For me, it's the
only way I use this when making/editing PDFs with GIMP, but maybe some
people would still want GIMP to crawl into groups and subgroups and
export layers individually. That's why I make it an option, defaulting
at TRUE.
Note that I didn't port "file-pdf-save-multi" at this point, though I
did move to using GimpProcedureConfig instead of GimpValueArray
everywhere.
In any case, that's a lot of code removal and simplification already,
though some part of this plug-in is still a bit ugly.
We also get proper config storing between sessions now.
As for metadata, it unfortunately doesn't look like Exiv2 has PDF
support, so I didn't add metadata settings.
… gimp_procedure_config_save_metadata().
If you use gimp_procedure_config_save_metadata() or
gimp_procedure_config_end_export(), you don't really control the flags
and let the GimpProcedure API make somes choices for you, based on
various assumptions. One of them is that the procedure has specific
properties (named "save-*", either created manually or with the various
gimp_save_procedure_set_support_*() functions). So if you don't have
them, we should assume this format doesn't handle a given metadata
format and deactivate it.
For plug-ins with a different/specific logic, they are expected not to
use these helper functions. They would likely call lower level functions
such as gimp_image_metadata_save_finish() or the newer
gimp_image_metadata_save_filter(), where you control the metadata flags.
The dl*() functions are in libc directly. This probably applies to all
*BSD too. And from what I read, it should even apply to macOS, even
though a libdl is present there (is it bogus?).
So let's make the libdl check proper by only make it mandatory on Linux
(on Windows it was already unchecked too).
Fix the Linux Input test to correctly only depend on whether or not the
header is present. Having X11 target is not enough (e.g. it breaks the
build for NetBSD and probably on all BSDs).
This file was just moved as content/core/specifications/locks.md in the
pat/bootstrap branch of the gimp-web-devel repository.
This branch will soon be merged and become our new website. Removing the
now duplicate in our source repo.
- Use a relative path for GIMP_LOGO_PATH inside the gi-docgen generated
HTML, and not an absolute path taken from build dir (otherwise this
would break, for installed docs, but also for the tarball and the
developer website!).
- Also use either gimp-logo.png or gimp-devel-logo.png depending on
whether we are on a stable or unstable branch.
- Install these in images/ inside the GIMP docs folder, which
corresponds to the relative path given to GIMP_LOGO_PATH.
- The installed root dir will be $datadir/doc/gimp-2.99/, e.g.
/usr/share/doc/gimp-2.99/
- Inside this folder, the library references will be in libgimp-3.0/ and
libgimpui-3.0/ (instead of weird Gimp-3.0/ and GimpUi-3.0/). Note that
the root dir uses the application version (2.99) whereas the library
folder use the API versions. These are different in development phase.
- Archive the gi-docgen installed files, not taken from the build dir,
to avoid packaging temp files, such as the .toml files. Note that
`g-ir-docs` files are still taken from the build dir, as we don't
install them yet.
- Finally package all this in a directory before archiving in a tar.xz,
named the same as the directory (e.g. gimp-api-docs-2.99.13/ inside
gimp-api-docs-2.99.13.tar.xz).
We were using GIMP_UNSTABLE extensively to differentiate development
from stable code. But there is actually another level of development
code. Basically GIMP_UNSTABLE tells you are on the development branch,
e.g. for current branches, that you are on 2.99.* versions (vs. 2.10).
This depends on the minor version oddness.
GIMP_RELEASE will tell you if it's a release or a in-between-releases
code. This works with the micro version which must be even on release.
Any odd number means you are basically using random git code.
There can be any combination of GIMP_RELEASE and GIMP_UNSTABLE. For
instance 2.99.12 is a release of the unstable branch, whereas 2.10.33 is
development code of the stable branch.
I use this first in the update code as we were using GIMP_UNSTABLE for
both concepts but it made it harder to test. Now:
* GIMP_DEV_VERSIONS_JSON environment variable is only available on
development code, not on release (whether stable or unstable).
* The weekly check limitation is also only for releases (dev code just
check at every startup to quickly detect issues and regressions).
* Whether to look on testing website or public website json file depends
on the code being a release or not.
* Finally only whether to check "DEVELOPMENT" or "STABLE" sections in
the json file depends on whether we are on stable or unstable
branches.
This was not working due to a missing port in glib.
Potentially could be contributed upstream to GLib.
(cherry picked from commit b391f9f5c8)
Conflicts fixed:
app/gimp-update.c
Fixes:
> gcc: error: unrecognized command-line options '-mmx'; did you mean '-mmmx'?
> gcc: error: unrecognized command-line options '-sse'; did you mean '-msse'?
This is shown in the About dialog when a new version is available, but
also in the debug dialog (also when a new version is available).
Of course, for stable versions, we should still show the main download
page (which I double-checked current code does).
This meson warning was only showing when configuring a cross-compilation
project.
Fixes:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': meson.has_exe_wrapper. use meson.can_run_host_binaries instead.
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
For meson, I want to be particularly careful and not follow the "Debian
testing" rule as it bit us by the past for babl.
But this bump is probably OK:
* Debian stable has meson 0.56.2.
* meson 0.56.0 was released on 2020-10-30.
* GIMP 2.99 is a dev branch with no end release date yet.
This should also fix this warning at configuration time:
> WARNING: Project specifies a minimum meson_version '>=0.53.0' but uses features which were added in newer versions:
> * 0.55.0: {'Calling "add_dist_script" with File, CustomTarget, Index of CustomTarget, Executable, or ExternalProgram'}
We missed it until now because it was only happening with tarball builds
where gitversion_h could be a files() object, unlike in git builds.
GIMP tried to open webp files as ani (animated cursor) files. The reason
for this is that for ani we had set the file magic as the first 4 bytes
should be RIFF.
However, RIFF is a container format, used by many different file formats,
among which is also webp.
This means that checking for RIFF is not specific enough.
Based on the info on http://fileformats.archiveteam.org/wiki/ANI
we will check the 4 bytes starting at offset 8 for ACON, which is
apparently the identifying part for animated icons.
Due to a typo in the config property "default-delay", loading of that
option and the ones after it, failed.
Because of this, default-chunks had an invalid value, which made our
export fail. After correcting the typo the export succeeds.
- Setting an exec_dir variable is an error. As meson docs says, if
relative, it is installed relatively to prefix anyway: "If this is a
relative path, it is assumed to be relative to the prefix."
On the other hand, it would make problems if someone tried to set an
absolute bindir.
Moreover it is a lot clearer now. When we want to install in the
binary directory unconditionally, then get_option('bindir') is the
meson way, hence the way to go.
- On the other hand, the `gimp-debug-tool` is installed either in bindir
for Windows or macOS and libexecdir for all other platforms, at least
that's how it's set in the autotools build. So let's keep both builds
consistent.
- Make a hopefully clearer description for enable-default-bin option.
Let's clarify this is just about creating unversionning links pointing
to versionned files.
- Adding an item in the "Optional Features" part of the summary listing
during meson configure, for better discovery.
For the ".exe" extension on Windows, I wished we had an $(EXEEXT)
equivalent on meson rather than trying to set it ourselves (are there
other platforms where we must set a different extension?). But I could
not find any.
and import as inches
When GIMP's display unit was mm, our PSD export converted the X and Y
resolution as if a conversion from mm to inch was needed.
However, PSD's resolution is always measured in pixels per inch, so a
conversion is never necessary.
Removing the conversion, resolves the issue.
created by Adobe Lightroom 5.1
Adobe products are known to write incorrect RichTIFFIPTC tags in TIFF
images.
Since libtiff correctly detects and handles this there is no real need
for end users to be warned. So instead of a warning we will only output
a message to stderr.
This is essentially the same check as done in gimp_image_set_resolution,
but doing it here means we can load the image instead of throwing an
error.
We still need to get replacement xres and yres values, because these are
used to compute layer_offset_x_pixel and layer_offset_y_pixel.
Image m2-d0f86ab189cbe900ec389ca6d7464713.tif from the imagetestsuite
is a fuzzed image with an invalid very high number for the channel count.
This causes GIMP to become unresponsive for a very long time. Possibly
trying to allocate memory for all channels or another cause related to
the high number of channels.
Let's go for a more "reasonable" limit of 99 channels like we also do
for Photoshop images and show a message when we find an image with more
channels.
When loading a TIFF image using a script/plug-in in non interactive mode,
we did not initialize the list of pages, causing a crash when trying to
access it.
So, always initialize this list when non interactive.
Due to a change in the format string in libtiff, warnings about unknown
fields were not filtered out anymore.
Adjust our filtering of warning messages so we catch this again since
end-users don't need to worry about this and we don't need the
possible extra issues.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
