[bug #30560] Help key behaviour matches neither OSX nor OPENSTEP

[Derek Fawcus]

URL:
  <http://savannah.gnu.org/bugs/?30560>

                 Summary: Help key behaviour matches neither OSX nor OPENSTEP
                 Project: GNUstep
            Submitted by: dfawcus
            Submitted on: Tue Jul 27 09:12:57 2010
                Category: Backend
                Severity: 3 - Normal
              Item Group: Change Request
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

(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.




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?30560>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/