Pass the GEGL tile-cache size, swap path, and thread-count to plug-
ins as part of their config, and have libgimp set the plug-in's
GeglConfig accordingly upon initialization.
If I override the `program` variable, and it is not found in PATH
environment, then it is NULL and the error message is unhelpful. Make
the return value of g_find_program_in_path() into a separate variable
instead, and only override `program` in the end, when we know it is
non-NULL.
(cherry picked from commit 87a9feb6d9)
... Windows installation of GIMP.
Our default installer installs 32-bit version of the various DLLs in
32/bin/ (under the installation prefix). Currently this additional
folder is simply added in the PATH, so it works most of the time.
Unfortunately the PATH is searched last for DLLs, and in particular, it
is searched after system directories. So it means that if any misbehaved
application is installing DLLs in system dirs (and in particular
incompatible/older versions of the same DLLs a GIMP plug-in uses), it
breaks the 32-bit plug-in.
SetDllDirectoryW() bypasses this order and the set folder is searched in
between the binary directory and the system dirs. We were already
setting this for our main bin/ directory, which was good for 64-bit
plug-ins, but this was not protecting 32-bit plug-ins. Now our code to
run plug-ins check the bitness of the executable before running it, and
updates the DLL folder accordingly.
The alternative 32-bit folder can be overridden by the configure option
--with-win32-32bit-dll-folder (default: 32/bin/). This option can only
be set when building for 64-bit Windows obviously.
Alternatively we could have put copies of 32-bit DLLs in a subfolder
with each 32-bit plug-in, but this is at best a terrible workaround, as
we would duplicate DLLs for every such case. And this would not have
protected third-party plug-ins which wish to use some of our DLLs.
Last alternative is to use AddDllDirectory(), but it works since Windows
7 with a given update only. And our current official support is any
Windows since Windows 7. So we don't want to use this right now (also
I'm not sure it would actually be much better than current
implementation, and it seems to have a bit more limitations than
SetDllDirectoryW(), though I have not tested).
(cherry picked from commit 91c139f4d0)
Add a gimp-register-file-handler-priority procedure, which can be
used to set the priority of a file-handler procedure. When more
than one file-handler procedure matches a file, the procedure with
the lowest priority is used; if more than one procedure has the
lowest priority, it is unspecified which one of them is used. The
default priority of file-handler procedures is 0.
Add the necessary plumbing (plus some fixes) to the plug-in manager
to handle file-handler priorities. In particular, use two
different lists for each type of file-handler procedures: one meant
for searching, and is sorted according to priority, and one meant
for display, and is sorted alphabetically.
Registering a full menu path as a procedure's menu label is now
forbidden and causes the procedure to be rejected.
Bump the plug-in protocol version so a pluginrc containing such cruft
is not used.
Return an optional tooltip from gimp_procedure_get_sensitive(), in
GimpPlugInProcedure, build that tooltip from the image types the
procedure works on.
...upon exporting an image
Step 1: make it configurable just like "Export EXIF" etc.
app, libgimp: add "export-color-profile" config option
Add it to the preferences dialog, and pass it on to plug-ins in the
GPConfig message. Add gimp_export_color_profile() to libgimp.
Nothing uses this yet.
Same as we did for binfmt-style lines, if the executable part (for
instance in `pygimp.interp`) is not an absolute path, let's allow
ourselves to find it in the environment $PATH.
(cherry picked from commit f3c5ed55c8)
So basically our binfmt set for Python simply never worked since we just
set 'python' and not a full path, but current code was not looking in
the $PATH environment. This was dead code. Now it's fixed.
(cherry picked from commit 6080178a39)
Current code of gimp_interpreter_db_resolve() was only resolving the
interpreter by the file extension when the file could not be opened for
reading or if it was empty/coult not be read. This basically made this
test completely useless.
Let's fix this. Now it will be run all the time, but simply at the end,
if shebang and magic failed.
(cherry picked from commit 8509117fe6)
Also remove all traces of it from the plug-in protocol and raise the
protocol version to 0x0100 (we now allow features and therefore
version bumps in stable, and the master protocol version should always
be higher). Fix the code that aborts plug-in startup on protocol
version mismatch, we can't use gimp_message() because we have no
protocol.
Pass the current icon theme directory to plug-ins through the
config message, and add a gimp_icon_theme_dir() libgimp function
for retrieving it. Note that we already have a similar
gimp_icon_get_theme_dir() PDB function, which we keep around, since
it can be used to dynamically query for the current icon dir,
unlike the former, and since it returns a dynamically-allocated
string, while the rest of the config-related functions return
statically allocated strings.
Use the new function, instead of gimp_get_icon_theme_dir(), in
gimp_ui_init(). This allows gimp_ui_init() to run without making
any PDB calls. Consequently, this allows us to start plug-ins that
call gimp_ui_init() without entering the main loop in the main app.
We're going to add a plug-in that displays an interactive dialog
while the main app is blocking waiting for an operation to
complete, and we need to be able to start the plug-in without
entering the main loop, to avoid the possibility of arbitrary code
being executed during the wait.
Bump the protocol version.
This will in particular fix the whole DLL hell problem since various
plug-ins are now asked to install all their mess (and in particular
their embedded DLLs on Windows) inside their subfolder, hence not
disturbing the correct functionning of other plug-ins installed side by
side.
This reverts commit 94b028bc39c7250997ee9883793e6649bf2490c7.
Dunno what breaks here, it just crashes, leave the commits there
instead of rebasing them away, as reminder...
so plug-ins cannot thaw what they haven't frozen, and the code
can clean up frozen stuff left behind by crashed or broken plug-ins.
Also redo the cleanup code so it only keeps track of the undo group
counts and freeze counts of what *this* GimpPlugInProcFrame did
itself. That should make it even stricter against broken code that
could mess up internals.
It doesn't look like it is actually much of a problem, but anyway it's
better to have non-absolute paths in config files when possible.
Thanks to jtojnar on IRC for reporting these (and MyPaint brush paths
from my previous commit).
In gimp_plug_in_open(), use gimp_spawn_set_cloexec() to prevent the
parent's end of the read/write pipes from being inherited by the
spawned plug-in, instead of passing the corresponding file
descriptors to the plug-in as command-line arguments, and having
gimp_main() close them.
Adding new command-line arguments to plug-ins is problematic, since
their ability to handle them depends on their protocol version,
which is only communicated after the plug-in is spawned.
Regardless, this is much simpler.
In gimp_plug_in_open(), use gimp_spawn_async(), added in the
previous commit, instead of g_spawn_async(). See the previous
commit for the rationale.
Since gimp_spawn_async() doesn't provide a mechanism to perform any
cleanup in the child before exec()ing, move the closing of the
parent's end of the read/write pipes from the app to the plug-in's
gimp_main(), passing the relevant file descriptors to the plug-in
through argv.
which is just a #define to g_assert for now, but can now easily be
turned into something that does some nicer debugging using our new
stack trace infrastructure. This commit also reverts all constructed()
functions to use assert again.
The attached patch avoids CRITICALs when executing Debug actions
with no images open.
1) do not run projection benchmark unless there is an image
2) memsize of pluginmanager member was incorrectly computed using
gimp_object functions for 2 GObjects
Update the dprod production of generated enum files to include
abbreviated value descriptions, as per the previous commits.
Add a comment for translators above the abbreviated descriptions,
specifying the full description they abbreviate.
...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.
More than 2000 lines of code less in app/, instead of
if (instance->member)
{
g_object_unref/g_free/g_whatever (instance->member);
instance->member = NULL;
}
we now simply use
g_clear_object/pointer (&instance->member);
We don't search recursively but only at the first level. If a plugin is
in its own subdirectory, the entry point has to be named the same (minus
extension) as the directory. For instance my-plugin/my-plugin for a
binary, or my-plugin/my-plugin.(py|exe|…).
This way, a plugin can load shared objects (libraries, other script
files, etc.) without polluting the main plug-ins directories, and in
particular without interfering with other plug-ins.
This is a first step to fix bug 757057 (DLL files which were used in
various plugins).
Commit 1e6acbd4e1 modified the
generated enum recipes to run gimp-mkenums from the source
directory, instead of the build directory, so that only the
basenames of the corresponding header files would appear in
the comment at the top of the generated files. This was a
mistake -- $(GIMP_MKENUMS) is expecting to be invoked from the
build directory.
Switch back to running gimp-mkenums from the build directory. To
avoid including the relative path from the build directory to the
source directory in the generated file, add a @basename@ production
variable to gimp-mkenums, which exapnds to the basename of the
input file, and use it instead of @filename@ in the recipes for the
generated enum files.
When regenerating an enum file, don't copy it back to the source
directory if it hasn't actually changed. This allows using a read-
only source directory where the enum header is newer than the
generated file, as long as they're not really out of sync.
OTOH, *do* touch the generated source-dir file even when unchanged,
in order to avoid re-running its recipe on the next build, however,
allow this to silently fail (which is harmless).
We check them into git, so this makes it easier to keep them in
sync when using a separate build directory.
Case in point -- this commit also syncs a few enum files that went
out-of-sync with their headers.
Ell