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: Garrick Meeker via Pro-apps-dev <email@hidden>
- Date: Mon, 18 May 2020 11:52:58 -0700
You also currently need to add any custom view to enable view bridging and get
dialogs to show up. Darrin worked out an example filter to demonstrate this.
I’ve filed a bug report to have this secret trick added to the official docs.
It sounds like you already have a custom view, but otherwise this can be very
confusing.
> On May 18, 2020, at 9:32 AM, Darrin Cardani via Pro-apps-dev
> <email@hidden> wrote:
>
> 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
_______________________________________________
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