bugGNUstep - Bugs: bug #30560, Help key behaviour matches neither...

Group
 
 

bug #30560: Help key behaviour matches neither OSX nor OPENSTEP

Submitter:  Derek Fawcus <dfawcus>
Submitted:  Tue 27 Jul 2010 09:12:57 AM UTC
   
 
Category:  Backend Severity:  3 - Normal
Item Group:  Change Request Status:  Wont Fix
Privacy:  Public Assigned to:  None
Open/Closed:  Declined
* Mandatory Fields

Add a New Comment Rich Markup
   

Sun 01 Nov 2020 11:47:28 PM UTC, comment #4: 

I'm declining this since there has been no feedback in 10 years.  Thx

Gregory John Casamento <gcasa>
Group administrator
Thu 23 Oct 2014 08:41:32 AM UTC, comment #3: 

What is the exact bug here? is it still about help or generally about key masks in events ? In case please open a specific bug.

Riccardo Mottola <rmottola>
Group Member
Tue 27 Jul 2010 11:40:10 PM UTC, comment #2: 

Oh dear,  this partially turned out to be a bug in my test app,  so the speculation about the help mode being triggered from the backend is rubbish.

However there are differences between OPENSTEP and OSX.

OPENSTEP generates NSFlagsChanged events and neither NSKeyUp nor NSKeyDown events (i.e. the key is a pure modifier).  The switch in to and out of help mode is in response to the flags being changed (beit in NSWindow or elsewhere).  Help mode is also exited as soon as an mouse click occurs;  key press/release while the help modifer is active generate NSKeyUp,NSKeyDown,NSFlagsChanged events as appropriate.


OSX generates NSKeyUp and NSKeyDown events,  updating the modifier flags,  but without generating an NSFlagsChanged event.  The NSKeyDown and NSKeyUp events both have the NSHelpKeyMask bit set.  Indicating the modifier is set before the key down,  and cleared after the key up.  The help key repeats normally.  The switch to help mode is in response to the key down,  and the key up does not exit help mode.
If the help key is still held down when a mouse click occurs,  then the system stays in help mode; key press/release while the help modifer is active generate NSKeyUp,NSKeyDown,NSFlagsChanged events as appropriate.

Which suggests one of two changes:
  1) Exactly emulate OSX
  2) Tidy up  the current mixed mode so that the NSFlagsChanged events occur around the NSKeyUp/NSKeyDown events.  Giving a key up event with the help flag set.

Derek Fawcus <dfawcus>
Tue 27 Jul 2010 10:21:51 AM UTC, comment #1: 

Actually,  OSX also treats it as a pure modifier.

The difference is that OPENSTEP exixts help mode upon help key release,  whereas OSX does not.

Another difference is that in OPENSTEP the key generates a normal flagsChanged: event whereas in OSX it does not,  however this is probably inconsequential.

Derek Fawcus <dfawcus>
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.

Derek Fawcus <dfawcus>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gcasa (Posted a comment)
  • -email is unavailable- added by rmottola (Posted a comment)
  • -email is unavailable- added by dfawcus (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-11-01 gcasa StatusNone Wont Fix
        Open/ClosedOpen Declined

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code