I'm studying the StrokeFilter sample plugin code to determine the logic of its GUI interaction with the flash GUI extension.
I have to say I'm a bit puzzled by this, and don't really understand why Adobe recommends implementing GUI using flash extensions; it doesn't fit in with the plugin-architecture.
Once the user selects Object > Filters > SDK > Dash, a GetFilterParameters message is sendt to the StrokeFilterPlugin.
The plugin then communicates with the flash GUI extesion to bring up the dialog.
After the user has entered his parameters, and pressed the [OK] button, the OkClickedFunc calback function is called. This function in turn makes the following call to the AINotifier suite:
This call cuases the Notify message to be sendt to the StrokeFilterPlugin. It is in the Notify method that the filter is applied to the selected paths.
If I select another path and select Object > Filtes > Apply Dash, the same parameters should be applied to the selected stroke. But (of course) nothing happens.
When Object > Filters > Apply Dash is selected, the StrokeFilterPlugin receives a GoFilter message, but this method does nothing. Actually, since the plugin returns after the GetFilterParameters is sendt, the StrokeFilterPlugin recives the GoFilter message once the dialog is displayed, and of course long before the user has pressed OK or Cancel.
This way, the entire GetParameters - GoFilter dichotomy of the plugin architecture is bypassed.
Of course, this is a problem because there is no way you can, using many modern GUI libraries, set up a dialog to display and wait till the dialog is dismissed, (and then check out what the user pressed) like you could with the ADM. Fore example the Cocoa [NSApp runModalForWindow] method returns imediately, not when the dialog is dismissed.
Of course, it is possible to work around this problem by defining a variable that keeps track of whether a dialog is displayed or not, and then add this check in the GoFilter method. Then you also have to remember the plugin parameters yourself.
But, wasn't the plugin architecture supposed to take care of this?
I guess you will encounter a simlar problem if you want to set up your filter to support actions(?).
Therefore, I wonder what the recommended practice is, and whether the Illustrator Development team is planning to change this arhitecture to accomodate the callback philosphy of modern GUI libraries. Will that change recommended practice.
Hoping that he doesn't have to do too much recoding for next release of AI
Yes, this is a major challenge with using Flash UI - the Stroke Filter sample really just provides a suggestion of how you might work around this limitation. I wasn't aware that this also affected Cocoa (I'm very new to Cocoa development and still learning) - you might find this link useful if you're running into this problem: http://marc-abramowitz.com/archives/2010/06/09/the-quest-for-a-better- uialertview/
But yes, I agree that the real issue is that the architecture isn't designed for these sorts of UI frameworks. For now I would try and use workarounds like the one above, or tailor solutions to the specific problem (like Stroke Filter is attempting to do).
Hope that helps,
Its probably worth noting that Filters are kind of deprecated now aren't they? We used to implement at lof our stuff as filters (even thought they prbobably shouldn't have been) and we've migrated them away from that model. When we did use them though, we used Qt, which acted very similar to the ADM in this regard so there wasn't a problem (other 3rd party toolkits would also work).