Tue 27 Jul 2010 09:12:57 AM UTC, original submission:
(This applies to back and gui combined)
On both OSX and OPENSTEP, the help key seems to operate as a function of their equivalent of 'backend'; in that overriding the key event handling in NSApplication so as to send events directly to a custom view (which consumes the events) still provides the help cursor mode, and the 'helpRequested' method call.
This suggests that changing to help mode, and the invocation of helpRequested: should be driven directly from the backend, and that the backend should not generate a NSHelpFunctionKey press/release set of events to the gui.
There is a difference in behaviour between OPENSTEP and OSX; on OPENSTEP the key acts like a pure non-toggle modifier (c.f. Shift), on OSX it is more akin to a momentary locking modifier.
On OSX one can release the help key and the help mode stays in force until the next event is inserted (click or key press), a click results in helpRequested: being invoked, whereas a key press simply leaves help mode and invokes the keyDown: method.
Since it seems OSX is deprecating the help mode&key (witness the lack of new mac keyboards with such a key), I propose that we should aim to implement something like the OPENSTEP behaviour, especially since it seems easier.
This will probably involve removing the calls to '[NSHelpManager setContextHelpModeActivate: YES]' from NSWindow and NSInputManager and instead having such a call in the backends.
|