Re: Retrieving plug-in parameters in custom view in FxPlug 4
Re: Retrieving plug-in parameters in custom view in FxPlug 4
- Subject: Re: Retrieving plug-in parameters in custom view in FxPlug 4
- From: Darrin Cardani via Pro-apps-dev <email@hidden>
- Date: Mon, 18 May 2020 09:32:42 -0700
Sergey,
Answers inline below:
> On May 17, 2020, at 7:09 PM, Sergey via Pro-apps-dev
> <email@hidden> wrote:
>
> Good day pro-apps-dev,
>
> We are in the process of porting our plug-in onto FxPlug 4 (right now we are
> still on v2.x) and we struggle with making the basic things work via XPC.
>
> Our plug-in has its own custom UI based on Qt which is triggered by a Push
> Button. I am following the FxSimpleColorCorrector example and have been able
> to create a custom view (just a regular rectangular NSView with a child
> NSButton; should you ask, I cannot use addPushButtonWithName for the purpose
> as its selector is handled in the background thread which is not suitable for
> UI tasks, its visual representation is not perfect either)
You can always use -performSelectorOnMainThread: or
dispatch_async(dispatch_get_main_queue(), …) to do things on the main UI thread.
> Now obviously, our custom dialog must be pre-filled with current values of
> the custom parameters. However the FxParameterRetrievalAPI_v6 seems to be
> inaccessible in the handler selector of the push button. The _apiManager
> apiForProtocol returns nil no matter what.
>
> Funny enough, in the FxSimpleColorCorrector example the
> FxParameterRetrievalAPI_v6 is accessible inside drawRect selector, but not
> accessible inside mouseDown (which is similar to my situation).
>
> Is there a reason why the interface is inaccessible in some selectors, but
> accessible in others? Can you suggest any solution/workaround?
In general we have to be careful to keep data exchange between the host and the
plug-in to a minimum to keep performance tolerable for users. So rather than
allowing all selectors to be used during every plug-in call, we now have to be
very selective and find creative ways to cache data on the plug-in, while still
being careful to keep it up-to-date. It’s can be difficult to get right
sometimes. One option right now would be to cache the data yourself for use
later on. Since you get called to generate the custom data, you know every time
it gets changed.
That said, please file a feedback issue and we’ll look into it.
Darrin
>
>
> Best regards,
>
> Sergey
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Pro-apps-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Pro-apps-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden