Setting can_load return value to false still load the plugin and show it up in host

[BeezBeez]

Hello. One of my video effects is set-up this way.

impl AdobePluginGlobal for Plugin {
	fn can_load(host_name: &str, _host_version: &str) -> bool {
		host_name.contains("Premiere") // Load on Premiere Pro only
	}
}

I can confirm when ran on AfterFX a breakpoint is hit here :

if !<$global_type>::can_load(in_host_name.to_str().unwrap(), in_host_version.to_str().unwrap()) {
                // Plugin said we don't want to load in this host, so exit here
                return $crate::sys::PF_Err_INVALID_CALLBACK as $crate::sys::PF_Err;
}

And the return instruction is triggered. But for some reasons I ignore I still can see it in the UI to drag it on layers.

I have tested to hide it on premiere but with the same unfortunate result.

What are your recommandations to load and show a plugin only on a specific host, is this a debug from Adobe's applications ?

Thanks !

[BeezBeez]

What I have tested so far today :

• In the build steps changing Info.plist CFBundlePackageType to SPFX, CFBundleSignature to PrMr and PkgInfo file content to SPFXPrMr work perfectly and completely hide the plugin on AfterFX. I am afraid this will not work on windows, since this build step doesn't exist when targeting windows.
• A solution that is possibly cross-platform is to change PiPl Kind and RequiredHost to SPFX and PrMr but this break the plugin and make in unloadable on all hosts for a reason I ignore.

[AdrianEddy]

I couldn't find any way to achieve that either. The official docs say that setting IAmObsolete out_flag should hide it from AE menus, but it doesn't. It does hide it from the menu, but only if it's set in PiPl, but that also hides in from Premiere, so that's useless

Another doc says that there can be a "Blocklist After Effect.txt" file in the plugins folders, but then it says this doesn't work for After Effects (???)

I tested all these methods and couldn't find any way to make it work.

You could detect in_data.is_after_effects() in setup_params and simply don't set any params, or add one param with a text explaining that the plugin is not available, or use out_data.set_error_msg()

[AdrianEddy]

I'm thinking to just remove can_load from the API completely, as it basically doesn't serve any purpose, since Adobe just ignores the output from the PluginDataEntryFunction2 entry point. This would obviously be a breaking change, but I think we already have breaking changes with 0.3

@virtualritz @mobile-bungalow what do you think?

[mobile-bungalow]

Yeah the idiomatic strategy for adobe software seems to be to fail at run time and make a modal error pop-up. I Think removing it is fine. You could return an error and then use the AEGP suite to remove the effect from whatever layer it is applied to. In the case of an AEGP you can just return an error modal.

[BeezBeez]

@mobile-bungalow method sounds hacky, but legit since adobe leave us no choice. Maybe we could craft an "helper" function to do that automatically in the API ?

Thus we could still have the can_load function and in the define_effect macro check for the can_load return value, if we are in after effects then show an error modal and remove the effect from the layer the user tried to apply it too.

[mobile-bungalow]

I think including an override to do that might be too much magic. Especially since it is a really unorthodox method of dealing with a plugin which should not receive any more messages. I think an example for a safe strategy for unloading and displaying an error message is the right path forward here if there is some precedent we want to set for version or environment gating plugins.

[BeezBeez]

Hey I don't know where to share this, but maybe it could be better if we organize around a discord server ?

I took the initiative to create one : https://discord.gg/XcrPeYjBTF

Sorry if this isn't the right place, but this repo doesn't have a discussion page and a discord server could allow us to share our knowledge, what we are working on, iterate fast, and develop the adobe rust community more. Share me your thoughts !

[AdrianEddy]

While I like Discord, I think this community is too small to have the discussion in a different place, it will be too scattered in my opinion. It's better to use the Discussions and Wiki here, so that everyone new stumbling upon this repo can immediately see everything.

Unfortunately I don't have the permission to enable Discussions on this repo, but hopefully @virtualritz can help us here

[mobile-bungalow]

I agree with Adrian. These conversations are important to such a small group of people, we should keep them open, on a platform that can be indexed and recorded. Github discussions is the correct medium for that.

[BeezBeez]

Great ! The main goal was to not open an issue just to have others opinions about something etc... Let's see if @virtualritz can enable discussions on this repo. Thanks guys !