[API] Allow hosts to get/set the last used filter

[0xC0000054]

This feature would allow a host to call G'MIC-Qt multiple times with different parameters, e.g. as part of a user's batch processing script.

This currently affects the 8bf plugin interface when used in Photoshop (and other 8bf hosts) that support batch processing using the saved parameters.
As G'MIC-Qt only remembers the settings for the most recent run, calling it multiple times from a script would produce unexpected results.

The proposed API would be something like:

struct LastFilterData
{
  GmicQt::InputMode inputMode;
  GmicQt::OutputMode outputMode;
  QByteArray data;
}

QString get_last_filter_name();
LastFilterData get_last_filter_data();
void set_last_filter_data(const LastFilterData& data);

get_last_filter_name would return the filter name as shown in the UI, e.g. "Cubism".
This allows the host to show the G'MIC-Qt filter name to the user.

get_last_filter_data would return a structure that contains the input mode, output mode and an opaque blob that represents the filter with its current settings.
This data would be saved by the host, and used to set the selected filter and mode settings in the G'MIC-Qt UI by calling set_last_filter_data with the filter data.

[c-koi]

Interesting.
In your use case, does the full GUI need to show up ?
If not, launchPluginHeadless(/* with params */) already does part of the job. Except it does not even show a progress dialog.
In any case, indeed, some functions to retrieve last parameters are missing...

[0xC0000054]

In your use case, does the full GUI need to show up ?

Yes, in Photoshop's automation / batch processing implementation users can reopen the filter GUI to edit parameters.

If not, launchPluginHeadless(/* with params */) already does part of the job. Except it does not even show a progress dialog.

I updated my API proposal to include the input and output modes, this would allow callers to use either of the launchPluginHeadless methods.

I am planning to continue to use the launchPluginHeadless method that shows a progress bar. While this goes against Adobe's UI documentation for plug-ins that support automation / batch processing, it provides a much better user experience with long-running effects.
Due to the design of the 8bf filter API there are already cases where the user would be prompted to save the modified image(s), and then have to manually import them.

[c-koi]

A slight redesign of the API is under progress...

[dtschump]

When it's ready, could you please ping @hallarempt as well to warn her about the API changes ?
I think they'd be interested to know it before Krita 5 release.

[c-koi]

@hallarempt , @0xC0000054

The API has now been reshaped. In particular, former launchPlugin* functions have been merged into a single GmicQt::run().
It allows to launch the plugin with or without a GUI and, if needed, with the parameters previously set by the user and retrieved using the lastAppliedFilterRunParameters() function.

You may obtain the last filter name using:

GmicQt::RunParameters parameters;
parameters = lastAppliedFilterRunParameters(GmicQt::ReturnedRunParametersFlag::BeforeFilterExecution);
std::string filterName = parameters.filterName();

See this comment about the ReturnedRunParametersFlag parameter.

The host_8bf.cpp, host_paintdotnet.cpp and host_krita.cpp files have been updated to fit this new API.