On Mon, Nov 13, 2017 at 3:03 PM Riccardo Mottola <[email protected]> wrote:
> Hi, > > Ivan Vučica wrote: > > > > Menu items should auto enable/disable depending on whether the target > > object supports the passed selector. > > > > 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? > > auto-enable already works that way. If you attach to NSFirst it goes > down the responder chain. > ...yes, I know, that's why I was pointing it out? :) > > > > > This works especially magically if you use target NSFirstResponder and > > target the “first responder” correctly. Depending on how Graphos > > works, this might be infeasible, of course. > > It works but it is not "enough". > > If I want to enable "copy" only if an object is selected I need to ask > my document or view if it has something selected inside. If you just > validate if your controller supports copy there still might be nothing > to do. > I wanted to go more "finegrained", up to the point where certain menus > are enabled only if certain things are selected. > I'm not sure you picked up on my suggestion :) Why not add the object that receives these things to the receiver chain? Or: why not have every selectable object as an NSView subclass? It could be infeasible given a codebase. But, if I was writing a new project where I wanted the menus to vary, I would do it this way -- it would also allow me to offload some of the 'is this selected?' logic. Or, if I need multiple selection, I could create a virtual responder or NSView.
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
