On Oct 20, 2013, at 6:37 PM, Kyle Sluder wrote:
>> 2. However, shortcuts that are not connected to any menu item, like ⌘-E
>> or ⌘-R,
>
> In the default non-document template, ⌘E maps to Edit > Find > Use
> Selection for Find.
Ah, hadn't seen that. How about ⌘R?
>> only cause menuNeedsUpdate:
On Sun, Oct 20, 2013, at 01:14 PM, Charles Srstka wrote:
> I've played around with this a bit more, using the standard Xcode
> non-document app template, and its behavior is actually quite weird.
>
> 1. Typing a keyboard shortcut that's connected to one of the items
> currently in the menu works
> On Oct 20, 2013, at 7:21 AM, Martin Hewitson
> wrote:
>
>
>> On 20 Oct 2013, at 01:15 am, Kyle Sluder wrote:
>>
>> Rather than rely on intercepting responder chain-based validation, wouldn't
>> it be much easier and more reliable to make some object the delegate of all
>> of your NSMenus
On Oct 20, 2013, at 3:14 PM, Charles Srstka wrote:
> 5. Validation definitely does *not* fire for unmapped keyboard shortcuts. It
> only fires if the keyboard shortcut in question is already mapped to an item
> that performs an action on the object which called validateMenuItem:, so I
> stand
On Oct 20, 2013, at 2:50 PM, Charles Srstka wrote:
> On Oct 20, 2013, at 2:37 PM, Ken Thomases wrote:
>
>> On Oct 20, 2013, at 2:29 PM, Charles Srstka wrote:
>>
>>> -menuNeedsUpdate: has the same problem that -validateMenuItem: has. It
>>> doesn't get called until the menu is about to be actua
On Oct 20, 2013, at 2:46 PM, "Mills, Steve" wrote:
>> On Oct 20, 2013, at 14:38, "Ken Thomases" wrote:
>>
>> This isn't correct. Menus are updated/validated when resolving keyboard
>> shortcuts. What makes you think otherwise? Lots of things wouldn't work if
>> that weren't so.
>
> For wh
On Oct 20, 2013, at 2:37 PM, Ken Thomases wrote:
> On Oct 20, 2013, at 2:29 PM, Charles Srstka wrote:
>
>> -menuNeedsUpdate: has the same problem that -validateMenuItem: has. It
>> doesn't get called until the menu is about to be actually drawn, which
>> doesn't happen until the user clicks on
> On Oct 20, 2013, at 14:38, "Ken Thomases" wrote:
>
> This isn't correct. Menus are updated/validated when resolving keyboard
> shortcuts. What makes you think otherwise? Lots of things wouldn't work if
> that weren't so.
For what it's worth, Cocoa's key equiv updating doesn't always work
> On Oct 20, 2013, at 12:37 PM, Ken Thomases wrote:
>
>> On Oct 20, 2013, at 2:29 PM, Charles Srstka wrote:
>>
>> -menuNeedsUpdate: has the same problem that -validateMenuItem: has. It
>> doesn't get called until the menu is about to be actually drawn, which
>> doesn't happen until the user c
On Oct 20, 2013, at 2:29 PM, Charles Srstka wrote:
> -menuNeedsUpdate: has the same problem that -validateMenuItem: has. It
> doesn't get called until the menu is about to be actually drawn, which
> doesn't happen until the user clicks on your menu.
This isn't correct. Menus are updated/valida
On Oct 20, 2013, at 2:02 PM, Kyle Sluder wrote:
>> On Oct 20, 2013, at 4:21 AM, Martin Hewitson
>> wrote:
>>
>>
>>> On 20 Oct 2013, at 01:15 am, Kyle Sluder wrote:
>>>
>>> Rather than rely on intercepting responder chain-based validation, wouldn't
>>> it be much easier and more reliable to
> On Oct 20, 2013, at 4:21 AM, Martin Hewitson
> wrote:
>
>
>> On 20 Oct 2013, at 01:15 am, Kyle Sluder wrote:
>>
>> Rather than rely on intercepting responder chain-based validation, wouldn't
>> it be much easier and more reliable to make some object the delegate of all
>> of your NSMenus
OK, I tried the suggestion to do the update in windowDidBecomeKey and this
works nicely with the following (perhaps a little ugly) code:
- (void) specialiseCloseMenu:(BOOL)state {
NSMenu *mainMenu = [[NSApplication sharedApplication] mainMenu];
NSMenu *fileMenu = [[mainMenu itemAtIndex:1] su
On 20 Oct 2013, at 01:15 am, Kyle Sluder wrote:
> Rather than rely on intercepting responder chain-based validation, wouldn't
> it be much easier and more reliable to make some object the delegate of all
> of your NSMenus and implement -menuNeedsUpdate:?
>
But wouldn’t this object then need
Rather than rely on intercepting responder chain-based validation, wouldn't it
be much easier and more reliable to make some object the delegate of all of
your NSMenus and implement -menuNeedsUpdate:?
--Kyle Sluder
> On Oct 19, 2013, at 1:28 PM, Andy Lee wrote:
>
> Uli and I both remembered t
Uli and I both remembered the app delegate is checked *after* the
window-related objects in the responder chain, which is what you discovered.
I *thought* you could work around this by changing the actions of the Close
menu items to methods that only the app delegate implements. But you really
On Oct 19, 2013, at 12:28 PM, Martin Hewitson
wrote:
> OK, so the idea is,
>
> + validateMenuItem in app delegate gets a first shot at setting the keyboard
> shortcuts
> + I override validateMenuItem in my tabbed window and reset the keyboard
> shortcuts
> + Other windows stick with the setti
On 19, Oct, 2013, at 08:59 pm, Michael Babin wrote:
> On Oct 19, 2013, at 1:32 PM, Martin Hewitson
> wrote:
>
>> I guess I didn’t understand correctly since my app delegate does not get
>> asked to validate the Close menu item. So far the only thing that get’s
>> asked to validate this is t
On Oct 19, 2013, at 1:32 PM, Martin Hewitson wrote:
> I guess I didn’t understand correctly since my app delegate does not get
> asked to validate the Close menu item. So far the only thing that get’s asked
> to validate this is the tabbed window object. Even the window’s delegate is
> not ask
I guess I didn’t understand correctly since my app delegate does not get asked
to validate the Close menu item. So far the only thing that get’s asked to
validate this is the tabbed window object. Even the window’s delegate is not
asked.
The documentation states:
For document-based application
OK, so the idea is,
+ validateMenuItem in app delegate gets a first shot at setting the keyboard
shortcuts
+ I override validateMenuItem in my tabbed window and reset the keyboard
shortcuts
+ Other windows stick with the settings arranged by the app delegate
Did I understand correctly?
Thanks
On Oct 19, 2013, at 9:04 AM, Andy Lee wrote:
> My first thought was that the app delegate might not get a validateMenuItem:
> message if something earlier in the responder chain handles those menu items.
> But you could change the actions of the menu items to something unique to
> make sure no
On 19 Oct 2013, at 15:04, Andy Lee wrote:
> My first thought was that the app delegate might not get a validateMenuItem:
> message if something earlier in the responder chain handles those menu items.
> But you could change the actions of the menu items to something unique to
> make sure nothi
On Oct 19, 2013, at 8:46 AM, Uli Kusterer wrote:
>
> On 19 Oct 2013, at 14:27, Andy Lee wrote:
>> On Oct 19, 2013, at 6:58 AM, Martin Hewitson
>> wrote:
>>> Main Window with tabs:
>>> close (cmd-shift-w)
>>> close tab (cmd-w)
>>>
>>> All other windows:
>>> close (cmd-w)
>>>
On 19 Oct 2013, at 14:27, Andy Lee wrote:
> On Oct 19, 2013, at 6:58 AM, Martin Hewitson
> wrote:
>> Main Window with tabs:
>> close (cmd-shift-w)
>> close tab (cmd-w)
>>
>> All other windows:
>> close (cmd-w)
>> close tab (inactive, no keyboard shortcut)
>>
>> This is pre
On Oct 19, 2013, at 6:58 AM, Martin Hewitson wrote:
> Main Window with tabs:
> close (cmd-shift-w)
> close tab (cmd-w)
>
> All other windows:
> close (cmd-w)
> close tab (inactive, no keyboard shortcut)
>
> This is pretty much the way things work in Xcode.
>
> So, my qu
Dear list,
I have an app with tabs and I’m trying to change the default 'close' keyboard
equivalent for only the main window which has the tabs. I’d like to have
Main Window with tabs:
close (cmd-shift-w)
close tab (cmd-w)
All other windows:
close (cmd-w)
close t
27 matches
Mail list logo
