Plugin registration in 3.0
Operating System: All
Description of the feature
As I understand it in Gimp v3, a plugin foobar
- Must be is a directory
foobar
in the plugin path - Is registered by identifying a
foobar
orfoobar.*
executable in the directory (and there can be only one such file, when there are several, all but one are ignored).
So, the plugin is wholly identified by the directory. In addition, the use of directories is the recognition that a plugin can be spread over several files (libraries, translations, configuration).
In light of this, considering only the timestamp of the executable to invalidate the cache data in pluginrc
is a bit restrictive, change to other files can also impact the registration result (a config file can enable/disable some options, and why should the registration code be in the main executable anyway?).
The proposed change is to have the time stamp in pluginrc
be the timestamp of the most recent file in the plugin directory, and refresh the cache if the more recent file in the directory is more recent than this time stamp.
As far as I can tell:
- For most existing single-file plugins there won't be any impact
- There should be little performance impact since the directory is scanned each time
Use cases
I have several v2 plugins that will register different procedures from a configuration, for instance:
- A set of guides
- A luminosity mask
- A hatching pattern
These are procedures (one set of guide = one procedure = one menu entry) so that they can be associated to keyboard shortcuts. Currently when users change the configuration files they have to do non-obvious things (such as touch
ing the executable, or erasing/altering pluginrc
) to make the changes visible. Implementing the above would make this unnecessary, the new configuration file would make Gimp re-register.
I see that in V3 there are the query
and init
calls, and init
could likely be used for this, but it is a bit of overkill since the configuration file rarely changes after a while.