With the new API introduced int d1c4457f,
we next need to port all plug-ins using
the argument macros to functions.
This will allow us to remove the macros
as part of the 3.0 API clean-up.
Adds PowerShell script and proper manifest for making .msixupload
(only for releases) and/or .msixbundle (always, for testing).
As authorized by Jehan, 32-bit willn't be supported. The reasons are:
1. 32-bit is going to die when WIA plug-in is done. This can hurt reviews
2. 32-bit is being restricted in ARM64 version. This causes disparity
3. 32-bit is generating a big footprint. "This is bad for the environment"
To be clear: we are discarding most of 32-bit artifact (see point 1)
and what could not (TWAIN for x64 only, point 2) almost doubles .msix.
There is one small circumstantial reason too:
4. 32-bit wouldn't have .pdb even after GCC 14 because bins have same name
as x64, and MS don't allow multiarch debug symbols in the same .appxsym
There was no user feedback when our twain plug-in couldn't find the
(32-bit) TWAIN driver, making for a poor user experience.
Especially since nowadays the availability of the twain driver is
less likely, let's add an error message for the user, so they will
know what's going on.
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.
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.
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
This is the consequence of previous commit. Plug-ins' label and
documentation are now localized before sending these data to GIMP core.
In other words, we replace N_() macros with basic gettext calls.
Hence avoiding the stderr messages. These are going to be localized with
centrally installed catalogs "gimp*-std-plugins", "gimp*-script-fu" and
"gimp*-python".
We now handle core plug-in localizations differently and in particular,
with kind of a reverse logic:
- We don't consider "gimp*-std-plugins" to be the default catalog
anymore. It made sense in the old world where we would consider the
core plug-ins to be the most important and numerous ones. But we want
to push a world where people are even more encouraged to develop their
own plug-ins. These won't use the standard catalog anymore (because
there are nearly no reasons that the strings are the same, it's only a
confusing logic). So let's explicitly set the standard catalogs with
DEFINE_STD_SET_I18N macro (which maps to a different catalog for
script-fu plug-ins).
- Doing something similar for Python plug-ins which have again their own
catalog.
- Getting rid of the INIT_I18N macro since now all the locale domain
binding is done automatically by libgimp when using the set_i18n()
method infrastructure.
Removed the WinMain specific stuff for the plug-in and determine
hInstance in twainMain which made porting a lot easier.
The _DEBUG enabled functions I have mostly left alone and
should be revised at a later time.
... since GEGLification of the twain plug-in (2.10.14 and later
versions)
In the data-transfer functions, allocate a temporary buffer for the
converted data on each call using the current chunk size, instead
of reusing the buffer allocated on the first chunk. This allows
for different chunks sizes across calls.
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.
I am going to forbid plug-ins from being installed directly in the root
of the plug-ins/ directory. They will have to be installed in a
subdirectory named the same as the entry point binary.
This may seem useless for our core plug-ins which are nearly all
self-contained in single binaries, but this is actually a necessary
restriction to eliminate totally the DLL hell issue on Windows. Moving
core plug-ins in subfolders is only a necessary consequence for it.
I'm sure some plug-ins need to add their items *not* at the toplevel,
but since making plug-ins really tree-aware is a lot more work than
just fixing insert positions, I went for passing -1 as parent in
almost all cases. And because of laziness...
Created a resource file for plug-ins and a rule to link it to them.
The application icon file is smaller than the default one, there's no
point in doubling the size of a plug-in executable just for an icon.
If no problems turn up, this will close the bug.
Alx Sa