This commit just changes our saving API (i.e. the GimpSaveProcedure
class) to take an array of drawables as argument instead of a single
drawable.
It actually doesn't matter much for exporting as the whole API seems
more or less bogus there and all formats plug-ins mostly care only
whether they will merge/flatten all visible layers (the selected ones
don't really matter) or if the format supports layers of some sort. It
may be worth later strengthening a bit this whole logics, and maybe
allow partial exports for instance.
As for saving, it was not even looking at the passed GimpDrawable either
and was simply re-querying the active layer anyway.
Note that I don't implement the multi-selection saving in XCF yet in
this commit. I only updated the API. The reason is that the current
commit won't be backportable to gimp-2-10 because it is an API break. On
the other hand, the code to save multi-selection can still be backported
even though the save() API will only pass a single drawable (as I said
anyway, this argument was mostly bogus until now, hence it doesn't
matter much for 2.10 logics).
This gives a big cleanup in the meson.build files of the plug-ins.
It's also quite a bit more maintainable, since anything that changes in
libgimp's dependencies, linkage, ... doesn't have to be copy-pasted into
each plug-in.
Add visual tab to spyrogimp plugin for a more intuitive, visual
way of specifying the spyrograph pattern.
In addition, fix using the selection as the fixed gear, and add
option to save the pattern to a path.
The GIR parser is giving warnings because both e.g. a signal, a
corresponding vfunc and a method emitting it are named
"channel_changed", which can and will give issues in some bindings.
The easiest option is to follow the general convention of starting the
signal emitters with `emit_`, which also makes clear the intention of
the method.
Change while() to go from 0..360 instead of 0..361 so the code passes
automated tests. The code never ran into this situation but the change
is a small improvement anyway.
For some reason we reverse the channel order when loading/saving a
PSD file. This doesn't seem to be necessary, and leads to a
reversed channel order across GIMP/Photoshop. Simply use the
normal channel order instead.
1 > warning: "_WIN32_WINNT" redefined
2 > pointer targets in passing argument 2 of 'send' differ in signedness
3 > passing argument 4 of 'setsockopt' from incompatible pointer type
For the signedness/type issues, I just casted to (void *) which was the
expected type for these parameter on the Linux API anyway. As for
Windows API (which was expecting char* for these various API), the
compiler just does the cast itself from void* without complaining
anymore.
On Windows, accept() wants an int for addrlen but on Linux, it wants a
socklen_t which is an unsigned int. So we can't just switch to gint as
proposed in !232 (if we do so, the signedness warning now happens on the
Linux build instead of the Windows one).
Fortunately it looks like socklen_t is actually typedef-ed to int in
Windows headers. So let's just use this type, which is much more proper
anyway as this variable is only used in functions which want this type
on Linux.
Fixes:
> warning: pointer targets in passing argument 3 of 'accept' differ in signedness
I am comparing absolute value of 2 double computation results. Might as
well just use fabs() instead of truncating both values to int.
Fixes the following:
> warning: using integer absolute value function ‘abs’ when argument is
> of floating point type ‘double’ [-Wabsolute-value]
Fixes the following bug:
> warning: absolute value function ‘abs’ given an argument of type
> ‘glong’ {aka ‘long int’} but has parameter of type ‘int’ which may
> cause truncation of value [-Wabsolute-value]
In file-psd, add support for exporting high bit-depth images. This
is currently limited to 16-bit images, since 32-bit images seem to
have a different structure (our loading code can successfully load
32-bit images exported by the plug-in, but not actual 32-bit PSD
files saved in Photoshop.) Higher bit-depth images are saved as
16-bit for now.
Note also that when saving a linear image with a built-in linear
profile the result is wrong (the image is exported with a linear-
TRC profile, but the data is perceptual), but this is a general
problem we have to fix, not restricted to the PSD plug-in.
Let's go with the logics "bottom layer is first", which is also the
logics in animated formats. Hence changing the layer order on loading
multi-page PDF.
I don't reproduce these build warnings in my build but frogonia reported
them:
> warning: 'strcpy' accessing 1 byte at offsets 0 and [0, 2147483645] may overlap 1 byte at offset 0 [-Wrestrict]
And indeed the man of strcpy() clearly states that "The strings may not
overlap" (which is clearly not guaranted in current code as we don't
know the size of what's after the substring).
strncpy() might have done the trick as it doesn't say anything about
possible overlap or not, but let's just use memmove() instead where it
is clearly written that memory areas may overlap (note that bcopy() as
proposed by ankh would have also done the trick, but it is marked as
deprecated).
… defaults to FALSE for PNG, TIFF.
The logics is that in most case, when alpha is 0, you don't expect color
to be retrieved and some people were bothered by this when erasing data
with eraser tool or selection deletion.
For the WIP image as well as for XCF format, we definitely want to keep
color data as there are workflows where you would want to erase/unerase
pixels subtly (selection also are not binary and should not be expected
to erase color data on layers with alpha channel). So we want to keep
the non-destructive behavior there.
Yet for export formats, going for "deleting what looks deleted" is a
valid approach, especially as it has been argued that experienced users
would know how to read and change the format options (and these
experienced users are likely the ones who may have valid reasons to want
pixels with full transparency to keep color values).
PNG and TIFF were the only 2 formats where I see such options, so
changing the default for these 2 plug-ins.
* Don't generate our own marshallers if they are available in GLib
already
* Don't set the c_marshaller parameter in `g_signal_new()` if it's a
default marshaller provided by GLib. See commit message of commit
39e4aa3c57 on why this is the case.
And by "supporting CR3", I mean sending the file over to raw developer
software which are supposed to support it! At the very least RawTherapee
support CR3 (since recent version 5.8 apparently), not sure about
darktable (but if not yet, I assume it won't be long either).
In the screenshot plug-in, don't clean the image, since it's not
backed by any persistent source, and disable undo while modifying
it, so that the initial edit history is clean.
gimp_int_radio_group_new() was still complaining about the scope of
radio_button_callback(). Make it (scope notified) because it needs to
stay alive after the function returns and may be called multiple times.
Also adding a GDestroyNotify to free the callback data once the widget
is destroyed (additionally it will also serve as a notifier for bindings
to properly free the callback closure itself, not only it's data).
With this last one done, GObject Introspection generation now happens
without any warning output.
… twice.
It should not be freed by the caller since it is annotated as (transfer
none). It gets freed when calling gimp_procedure_config_end_export().
Thanks to Massimo for noticing.
When the "Omit hidden layers and layers with zero opacity" option is
set, this property was only checked on non-group layers. So if we had
non-hidden layers inside hidden layer groups, they ended up exported,
which is not the expected behavior.
See https://gitlab.gnome.org/GNOME/gimp/issues/4425#note_675350
Adds a new PDF export option "Convert text layers to image", which
defaults to FALSE (because text staying text is obviously usually
prefered).
Also loop through text layers to detect missing fonts. In case any are
found, add a warning in the export dialog, below the new option,
advising to enable this option if design matters (if fonts are missing,
PangoCairo seems to select any other random font and embed it into the
PDF instead of the expected one).
Without the write permission for the owner, the `make install-plug-ins`
special target fails on Python plug-ins. And anyway I don't see a reason
why not give write permission to the owner (like all other plug-ins are
installed).
There is no reason to limit it to "xhtml" only. Even more, in all
browsers I tried, the exported page was failing to load with the '.xtml'
extension, while it loads fine when renamed as '.html'.
Only problem is that now we have 2 plug-ins able to save as html (other
is file-html-table) and the first in the procedure list (with no
explicit logics right now) will just shadow the next one. We will have
to add some generic infrastructure to allow people to choose favorite
load/export plug-ins, probably in Preferences, next to the raw plug-in
selection.
I made the various static arrays in headers declared as extern and
defined in a separate implementation file, with additional size constant
when necessary (since G_N_ELEMENTS() cannot be used on partially
defined arrays).
Note that this is better than the original implementation, yet I am not
saying this is ideal either. I am not fond of such code organization and
think a better one could be done. But it would require to dive deeper
into this plug-in and I don't want to right now, nor have the time.
At least now it stopped shouting all these warnings!
This cleans just a third of the warnings in this metadata plug-in. It is
a very bad practice to define static const strings in a header file like
this, especially if this header is included in several files. Let's make
these macros.
Also why are these header tags sometimes used with the const name (now
macros), sometimes directly with the string literals? I fixed some of
these, but more string literals are lying around.
Remaining warnings are similar, about const string arrays. If really we
want this, we should declare these extern and define them in a separate
implementation file. This whole plug-in should be really reorganized and
cleaned in depth.
Variable ai and ai_curr going out of scope at line 496.
Variable ai going out of scope at line 545.
Revealed by Coverity Scan.
(cherry picked from commit 1ce1b0eebe)
There were 2 warnings of unused functions on this file, and masking
them, we were ending with a whole file #ifdef-ed 0. So let's just get
rid of the whole useless file.
My commit c77c903c8d was obviously wrong since I realize that by fixing
the C plug-in installation, I broke non-C goat-exercise plug-ins
installation. This fixes it.
which removes quite some boilerplate. Also remove the boolean
"profile_saved" return value of save_image() and instead modify the
config. Add a "bits_per_sample" return value and set value on the
metadata instead of always "8".
Now takes an integer index into the aa_formats array instead of the
format's name. "4" is about as magic as "weird aallib format name #4"
so no harm done.
and add boolean arguments to control comment and hot-spot
writing. This revives comment writing, which is disabled by default
and comes with a big warning in the dialog.
and remember them internally between begin_run() and end_run().
Simplifies plug-in code even more.
Move the begin_run() before gimp_export_image() block in all export
plug-ins.
and remove a gazillion gtk_widget_show() all over the place, some
places need a gtk_widget_hide() now, and I'm pretty sure I broke at
least one thing in all those files...
Remove the save dialog's builder file and construct the dialog
manually, which is actually less and more obvious code thanks to
propwidgets, which are not suited for a builder GUI.
I guess file-png-save counts as a real test for the new procedure
config stuff, and it seems to work nicely. The only thing that's a bit
ugly is the GimpMetadata integration which doesn't exist yet.
and use the changed gimp_int_store_new() in the dialog. It appears
to be a straightforward way to replace gimp_int_radio_group_new()
which should really go away for 3.0.
and use the new feature of saving the last config in an image
parasite.
In app/file-data/fie-data-gbr.c, manually construct the same parasite
when loading a brush, so its spacing and description are stored in the
image.
This replaces the "gimp-brush-name" parasite which is now obsolete.
When non-NULL, the code tries to load/save image-specific last used
values from/to the image using a parasite. This is meant to be used by
file export plug-ins.
This function returns a HINSTANCE (which is technically a pointer if I
understand correctly) for backward compatibility reason. But this is
actually meant to be used as an int only according to the docs.
Yet casting to gint outputs "cast from pointer to integer of different
size" warnings.
We should use intptr_t instead for such cases, since it is a type made
explicitly to hold a pointer as int, hence should always be right on any
platform.
https://docs.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shellexecutea
The second parameter should be GStatBuf*, which will be defined to be
the right struct depending on the actual platform. Using `struct stat*`
was good on Linux but was outputting warnings on other platforms (at
least on Win32).
When cross-compiling for Windows, I had this warning:
> plug-ins/file-ico/ico-load.c:221:22: warning: format '%lu' expects
> argument of type 'long unsigned int', but argument 5 has type 'long
> long unsigned int' [-Wformat=]
I guess that on some platform sizeof may be a long long uint. Just cast
the result to long uint instead (I could have done the other way around,
but I doubt the struct type IcoFileEntry would ever get bigger than long
uint max!).
It was installing in separate dirs `goat-exercise/goat-exercise` and
`goat-exercise-c/goat-exercise-c.c`. This is obviously wrong as the C
raw file is obviously not a plug-in of its own, it is just a data for
the built plug-in to be displayed as source.
Anyway now fixed to work like the autotools build.
Scripts must be able to pass values to procedures even if they have no
idea what the actual parameter type is (item, uchar, layer mask), to
the script it's all just numbers anyway.
They are semantically wrong anyway because they work on drawable,
assuming that the drawable is encoded in whatever non-RGB pixel (while
getting data in R'G'B'A format). This is just an internal trick of the
file-dds plug-in which converts DDS data internally instead of having
babl doing the job by making appropriate formats.
Anyway we should definitely not expose such procedure publicly. I am not
deleting the code directly, just hiding it away in `#if 0` for now.
```
../../gimp/plug-ins/common/file-psp.c: In function 'load_image':
../../gimp/plug-ins/common/file-psp.c:1930:25: warning: passing argument 2 of 'g_stat' from incompatible pointer type [-Wincompatible-pointer-types]
1930 | if (g_stat (filename, &st) == -1)
| ^~~
| |
| struct stat *
In file included from ../../gimp/plug-ins/common/file-psp.c:44:
C:/msys64/mingw64/include/glib-2.0/glib/gstdio.h:134:31: note: expected 'GStatBuf *' {aka 'struct _stat64 *'} but argument is of type 'struct stat *'
134 | GStatBuf *buf);
| ~~~~~~~~~~~~~^~~
```
Align plug-ins/common/meson.build with plugin-defs.pl, avoiding
building optional plug-ins whose dependencies aren't met.
Fix the build condition of the mail plug-in.
and in an attack of madness, changes almost all file plug-in
code to use GFile instead of filenames, which means passing
the GFile down to the bottom and get its filename at the very
end where it's actually needed.
Jehan