[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: issue with auto-enable of Menus

From: David Chisnall
Subject: Re: issue with auto-enable of Menus
Date: Tue, 14 Nov 2017 10:01:58 +0000

On 13 Nov 2017, at 19:58, Wolfgang Lux <address@hidden> wrote:
>> Am 13.11.2017 um 19:13 schrieb David Chisnall <address@hidden>:
>>> On 13 Nov 2017, at 17:52, Wolfgang Lux <address@hidden> 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 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]