078e283f4b
The gimp app and extension-script-fu (long-running) are separate processes and "apps." An app can be "active": in front and receiving GUI events. As reported, on MacOS, when an extension-script-fu plugin yields, the gimp app did not become active. Also, on the second invocation of a plugin served by extension-script-fu, the dialog could be hidden or require an extra click because extension-script-fu was not active. (Independently interpreted plugins did become active, because it was a new process and gimpui_init activates on MacOS.) On MacOS: 1. after the first dialog shown by extension-script-fu, ensure subsequent calls to plugin make extension-script-fu active. 2. After a plugin yields, plugin manager ensure the Gimp app is active. Note that this is done whenever a TEMPORARY procedure returns. Most are calls to extension-script-fu plugins. But some are also callbacks from Resource choosers running in the gimp app. When they return, the gimp app remains active, and user must first click in the plugin dialog to continue working. Especially when the user clicks OK in a Resource Chooser, closing the chooser, it would be nice if the plugin dialog became active. That requires more, FUTURE development. Special to MacOS: on Linux, "transient for foreign window" ensures this, but that doesn't work on MacOS. The fix is somewhat brute force and as simple as possible. There is a more cooperative API for app activation on MacOS. An app yields, and apps request, not force, self or other app be activated. The fix does not use the cooperative API. To do so would require a platform abstraction layer, in GIMP or Gtk. The fix also sprinkles the code with #ifdefs. That could be hidden if there were a platform abstraction layer PAL The layer would be the greatest common denominator across platforms. PAL methods would always be called in GIMP code, but not do anything when the effect was accomplished another way. For example "gimp_platform_request_app_active" would request the app was active, but do nothing on Linux where that is ensured by "transient for." |
||
|---|---|---|
| .. | ||
| ftx | ||
| tinyscheme | ||
| meson.build | ||
| README | ||
| scheme-marshal-return.c | ||
| scheme-marshal-return.h | ||
| scheme-marshal.c | ||
| scheme-marshal.h | ||
| scheme-wrapper.c | ||
| scheme-wrapper.h | ||
| script-fu-arg.c | ||
| script-fu-arg.h | ||
| script-fu-color.c | ||
| script-fu-color.h | ||
| script-fu-command.c | ||
| script-fu-command.h | ||
| script-fu-compat.c | ||
| script-fu-compat.h | ||
| script-fu-dialog.c | ||
| script-fu-dialog.h | ||
| script-fu-enums.h | ||
| script-fu-errors.c | ||
| script-fu-errors.h | ||
| script-fu-interface.c | ||
| script-fu-interface.h | ||
| script-fu-intl.h | ||
| script-fu-lib.c | ||
| script-fu-lib.h | ||
| script-fu-proc-factory.c | ||
| script-fu-proc-factory.h | ||
| script-fu-progress.c | ||
| script-fu-progress.h | ||
| script-fu-regex.c | ||
| script-fu-regex.h | ||
| script-fu-register.c | ||
| script-fu-register.h | ||
| script-fu-resource.c | ||
| script-fu-resource.h | ||
| script-fu-run-func.c | ||
| script-fu-run-func.h | ||
| script-fu-script.c | ||
| script-fu-script.h | ||
| script-fu-scripts.c | ||
| script-fu-scripts.h | ||
| script-fu-types.h | ||
| script-fu-utils.c | ||
| script-fu-utils.h | ||
| script-fu-version.c | ||
| script-fu-version.h | ||
| script-fu-widgets-custom.c | ||
| script-fu-widgets-custom.h | ||
| script-fu.def | ||
About libscriptfu libscriptfu is part of GIMP. It is not generally useful except by GIMP. The libscriptfu library is used by plugin executables, and the PDB procedures they create, all part of the "ScriptFu" machinery. The libscriptfu library is not intended for third-party developers, only for core GIMP developers. Headers for libscriptfu might not be installed. This directory contains three libraries: libscriptfu, tinyscheme, and ftx. The tinyscheme library contains a TinyScheme interpreter. The ftx library extends the TinyScheme interpreter, adding file functions to the Scheme language. The libscriptfu library contains both the tinyscheme and ftx libraries. The libscriptfu library wraps the TinyScheme interpreter, specializing it for GIMP. The script-fu executable uses the libscriptfu library, to interpret Scheme scripts that GIMP users refer to as "plug-ins." These libraries depend on other libraries, e.g. math, libgimp, glib, etc. Coupling between the executables and the libraries should be in one direction: source for the inner libs should not include headers from the outer executables. This lets you more easily update the inner libraries (which originated elsewhere and might be maintained elsewhere), and change the outer executables (which are subject to change by GIMP developers.) Example (which may change): The script-fu executable is a plugin file that implements PDB procedures: extension-script-fu, script-fu-console, script-fu-text-console, script-fu-eval, and script-fu-server. Each of those PDB procedures runs as a separate process. Each of those processes uses libscriptfu. The main PDB procedure is extension-script-fu, which is a long-lived process. It is a PDB procedure of PDBProcedureType EXTENSION. It interprets the Scheme scripts that user's call "plug-ins." Rarely two of the PDB procedure processes run concurrently. When they do, and libscriptfu is built as a shared library, the read-only, code portion of the library is only loaded in memory once.