When the setter method - setRerun: implemented as part of GlyphsFilter protocol is called for each filter plugin, for some reason NO always seems to be passed as the argument. Thus, at the moment there is no way for filter plugins to tell if it’s really a re-run or not.
It looks it reproduces both on Glyphs 2/3. Hope it’s addressed when you have time.
Yep, I agree that it’s not that useful in the end. And thanks for explaining your original intention.
I was just reluctant to make a dialog to accept options, so I took a shortcut by testing [[[NSApplication sharedApplication] currentEvent] modifierFlags] & NSEventModifierFlagOption so that the alternative strategy can be activated in my filter implementation only when the Option key is being pressed. When Command + R is going to be pressed consecutively, I thought it should make more sense to re-use the same option as before, and that’s why I dug into the rerun property.
At this point, I ended up to use the following snippet
as a workaround to determine if it’s indented to be a re-run. That kind of scenario might not be common, so I started to think that leaving the property as it is would be reasonable. I just didn’t expect that the argument will always be false regardless of the re-run state.
Yes, the problem I had was that the Option + Command + R combination collides with the one in the Script menu. Having multiple key equivalents in a single menu item is not possible AFAIK (without adding a hidden menu item), and I’m afraid pressing extra modifiers might not work for menu items. But anyway, thank you very much for the suggestion!
I found out that the technique I originally wanted to implement was described in the thread above. I know that’s a breeze in .xib, but the current filter plugin protocol is allowed to have only one dedicated menu item per plugin, so my assumption is that we can’t have an alternate menu item or multiple keyboard shortcuts (with modifier variations) unless we duplicate the plugin. It is technically possible to manipulate the main menu after the plugin has been loaded, but I would avoid that to keep my plugin concise.
I know filters are not meant to provide a menu item that behaves like Edit > Paste Special, so the current situation is completely okay for me, and my NSEvent-based hack is working nicely so far. Otherwise I should go implement a proper dialog!
Thanks for the information, I didn’t notice that there was such a nice addition for Glyphs 3! The shortcut feature looks so powerful and extensible. I’ll definitely consider using it where it doesn’t need compatibility with Glyphs 2.
I expect the corresponding Python API like above will be added to GlyphsSDK when Georg feels it’s stable.
While off-topic, Kotlin/Native supports Swift-ish name translation for Objective-C methods. I suppose the whole interop will get more Pythonic (and less mouthful) by itself if it lands on PyObjC in future, and that’s what I’ve been wanting for ages…