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.
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).
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.
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.
It's just too weird to be public. Remove its properties from the wire
protocol and from pluginrc. Instead, have all GParamSpecs' flags on
the wire and in pluginrc, so we can use stuff like
GIMP_PARAM_NO_VALIDATE.
Port the remaining few places to GIMP_PROC_ARG_STRING().
I'm sure something is broken now wrt UTF-8 validation,
will add tighter checks in the next commit.
... provided by RawTherapee's installer (version 5.5+).
See https://github.com/Beep6581/RawTherapee/issues/4783.
This patch required a small change to file_raw_get_executable_path
because the RawTherapee installer is supposed to work without admin
privileges and therefore can't write to HKLM.
Reviewer's note (Jehan): RawTherapee's installer does not add the
registry entry yet. We assume the upstream bug report will end up doing
so (someone has to make the first step!). :-)
When cross-compiling, I got various linking errors for printf() calls:
> undefined reference to `libintl_printf'
I am unsure why, since this is not recent code, and it used to build
fine with mingw64 compilers (last I cross-built, which is many months
ago). Anyway g_printf() works fine, all necessary libs are already
linked, and it is supposed to be a synonym. So let's just go the easy
way and use g_printf() only.
(cherry picked from commit c49afa4f84)
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 just cross-compiled for Windows after a long time. The header file is
all lowercase on a cross-compilation MinGW-w64 environment. I'm not sure
what is the case on Windows, but since this platform is case-insensitive
for file names, I believe this won't break anything on native builds.
I realize that on Fedora 27, the output of `darktable --version` is:
"this is darktable darktable-2.2.5-4.fc27"
This is different from the expected output in our plug-in ("this is
darktable 2.2.5"). I assume this version string can be customized and
distribution packagers will use the capability. So a regular expression,
in a slightly more flexible fashion would be better. I still assume that
the version string with start with "this is darktable", but then I
accept any non-number string until I reach a common major.minor.patch
version-looking string.
otherwise, implicit transitive linking will pull in the installed
libs, not the ones from the source tree, and the build can fail when
any of the libs' APIs changes.
Also remove some useless #includes.
Apparently Lua chokes when it sees c:\darktable\... as a path to a script,
thinking the '\d' was an escape sequence. Thus we have to add an extra
layer of escaping. Houdini like. Who came up with the brilliant idea to
use '\' as a separator anyway? So much pain just to be different?
Otherwise people will install older versions and won't understand why
the plug-ins won't work. It's just a little annoying that these version
strings have to be hardcoded this way. We could add macros in a header,
but that would be only half a solution. Ideally we'd rather have some
discovery logics at some point.
Hopefully it works, since that's untested (I have no MacOS access). This
is mostly code from file-darktable.c, made generic and factorized into
file-raw-utils.[ch]. At least it still builds and work fine on Linux.
I used the CFBundleIdentifier from `tools/osx/Info.plist.in` in
RawTherapee code. I didn't add a Win32 registry key base though, since I
couldn't find any relevant data for this in RawTherapee code.
...with known plugins
Add new plug-in file-raw-placeholder.c that registers itself for
loading all RAW formats from file-raw/file-formats.h, but does nothing
except returning an error message pointing to darktable and
RawTherapee.
When no real RAW loader is installed, this plug-in is selected
automatically as RAW loader, otherwise the first installed RAW loader
is used. Selecting another in prefs still works as before.
Niels De Graef