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.
jpeg-save.c:56: warning: "DEFAULT_QUALITY" redefined
56 | #define DEFAULT_QUALITY 90.0
|
In file included from C:/msys64/mingw64/x86_64-w64-mingw32/include/windows.h:71,
from C:/msys64/mingw64/x86_64-w64-mingw32/include/rpc.h:16,
from C:/msys64/mingw64/x86_64-w64-mingw32/include/objbase.h:7,
from C:/msys64/mingw64/x86_64-w64-mingw32/include/shlwapi.h:16,
from C:/msys64/mingw64/include/jmorecfg.h:19,
from C:/msys64/mingw64/include/jpeglib.h:31,
from jpeg-save.c:33:
C:/msys64/mingw64/x86_64-w64-mingw32/include/wingdi.h:1140: note: this is the location of the previous definition
1140 | #define DEFAULT_QUALITY 0
It's an ancient concept from ancient times when we didn't have URIs
and only filenames (not to speak of GFile), and actually even from
before the ancient time before that ancient time when we first had
ones and zeros, and only had zeros.
The exact warning was:
> (goat-exercise-gjs:26895): Gjs-WARNING **: 15:59:18.382: Some code
> called array.toString() on a Uint8Array instance. Previously this
> would have interpreted the bytes of the array as a string, but that is
> nonstandard. In the future this will return the bytes as
> comma-separated digits. For the time being, the old behavior has been
> preserved, but please fix your code anyway to explicitly call
> ByteArray.toString(array). (Note that array.toString() may have been
> called implicitly.)
Michael Natterer