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.
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.
...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.
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.
Since commit 9c8a8ae576, we don't run gimp_quit(), which properly quits
the plug-in executable, to make sure that GIMP gets the information that
it crashed. Instead quit with `exit (EXIT_FAILURE)`.
Drmingw already added its own exception handler which generates crash
traces in a text file, for plug-ins as well. This additional handler is
run after Drmingw handler and allows us to do things on our own, and in
particular we could display the content of the debug traces.
Right now it simply prints these to stderr, which actually won't be of
much use on Win32, first because the console is deactivated on stable
releases, also because after tests, it doesn't look like even running
GIMP from cmd outputs to console either.
We currently don't use the same debug dialog as the core on purpose,
because we don't want everyone to send us traces for every unmaintained
third party plug-ins out there. But we should definitely allow easier
trace possibilities at some point, first to improve/debug our own core
plug-ins, and also to help third party plug-in developers!
So this commit is not making visible changes yet but is actually a first
step towards these debugging goals.
When ending with gimp_quit(), GIMP was not displaying the "Plug-in
crashed" error dialog, which is not good, since we lose the crash
feedback for plug-ins. Just let the plug-in continue its normal run in
order to get the error dialog.
Also protect the tracing functions, which are not working on Win32.
SIGABRT was in the switch list in gimp_plugin_sigfatal_handler(), but it
had not been properly handled with gimp_signal_private(), making this
switch case useless. Fix this oversight, and while doing so, move it in
the "fatal error" list for which we may generate stack traces, similarly
to core signal handling. Indeed this signal can definitely happen during
various kinds of common bugs and needs to be debugged.
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.
Our own implementation is much better.
I don't make it into a GUI yet, but at least the CLI option will use the
new implementation in plug-ins as well, which will be quite useful.
... procedure call.
This is needed for plug-ins which depends on other plug-in's procedures.
If for instance, the second-level plug-in is interrupted interactively,
we don't want to process this as an error but as a cancellation.
Therefore we need to know the returned value of the plug-in. Currently
only way was to use gimp_get_pdb_error() but that was returning a
human-readable error, not a computer-processable error.
...protocol calls.
Some calls are waiting for answers, for instance plugin procedures, and
tiles which expects data and acknoledgement.
This would result in error messages such as:
"expected tile ack and received: 5" (5 is GP_PROC_RUN)
Typically because a thread would run a procedure while another would
receive tiles.
because it confuses gtk-doc and breaks some links. Also change the
"Index of new symbols in GIMP 2.x" sections to be what seems to be the
modern standard (looked at the GLib and GTK+ docs), and update some
other stuff.
Looks like they were forgotten so messages from libs went to stdout
instead of being routed through the log handlers, which would show
them in a dialog, or in the error console.
With this patch, there should be no more need to set PATH on Windows
before running GIMP.
This patch was tested by me and drawoc, but there could be some
undetected issues lurking. Revert if any problems arise.
It is advised to use the more accurate g_io_channel_win32_new_fd() or
g_io_channel_win32_new_socket() because GLib can't differentiate between
file descriptors and sockets on Windows, which outputs a warning when
there is ambiguity.
Apply patch from Hartmut Kuhse that enables plug-in debugging on
Windows by stopping the process using Windows API, and providing a
small executable "gimp-plugin-resume.exe" to resume the stopped
plug-in.
On OSX, call [NSApp activateIgnoringOtherApps] when a plug-in dialog
is shown, so the plug-in process becomes the active app, and the
dialog gets focussed.
In order to avoid doing this in GimpDialog (which is also used in
the core), do it in gimp_ui_init() which all interactive plug-ins
call, and when gimp_temp_proc_run() is called interactively, to
catch repeated activation of an already running plug-in.
Also, set GimpDialog's initial position to GTK_WIN_POS_CENTER,
or they will pop up in the top left corner.
Inspired by patches from Simone Karin Lehmann and Daniel Sabo.
