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.
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.
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.
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.
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).
… 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.
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.
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.
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.
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 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.
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.
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
"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.
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.
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.
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.
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.
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.
