Re: issue with auto-enable of Menus

[David Chisnall]

On 13 Nov 2017, at 19:58, Wolfgang Lux <wolfgang.lux@gmail.com> wrote:
> 
>> Am 13.11.2017 um 19:13 schrieb David Chisnall <theraven@sucs.org>:
>> 
>>> On 13 Nov 2017, at 17:52, Wolfgang Lux <wolfgang.lux@gmail.com> wrote:
>>> 
>>>> Would it make sense to not have custom code to enable/disable menu items, 
>>>> and just have appkit do it for you depending on the target?
>>> 
>>> In my experience, custom code is unavoidable in almost any non-trivial case 
>>> because the AppKit is not able to determine exactly when a menu item is 
>>> applicable and when not. Having support for the selectors is a necessary 
>>> but not a sufficient condition.
>> 
>> IOKit improves this relative to AppKit by adding the delegates to the 
>> responder chain.  For custom views, I’ve taken to doing this and forwarding 
>> some of the responder chain queries to the delegate.  It would also be nice 
>> if there were some convention such as {selector}IsEnabled, so if you 
>> implement -paste: and -pasteIsEnabled then you can turn off paste by 
>> returning NO to -pasteIsEnabled.
> 
> Well, that almost exists in the form of -validateMenuItem: and 
> -validateUserInterfaceItem:. It’s just that you implement just a single 
> method that receives a selector argument rather than an individual method for 
> each selector.

Yup, and whenever I write one of these I end up with a horrible blob of if 
statements.  In a language with dynamic dispatch, it would be nice for the menu 
item to just do NSSelectorFromString once, get the method that dynamically 
[de]activates it, and call that.  We’re already doing a bunch of message sends 
to deliver things down the responder chain, one more wouldn’t have visible 
overhead.

David