On 13 Nov 2017, at 19:58, Wolfgang Lux <[email protected]> wrote: > >> Am 13.11.2017 um 19:13 schrieb David Chisnall <[email protected]>: >> >>> On 13 Nov 2017, at 17:52, Wolfgang Lux <[email protected]> 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 _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
