> Am 14.05.2020 um 13:14 schrieb Fred Kiefer <fredkie...@gmx.de>: > >> Am 14.05.2020 um 12:22 schrieb Josh Freeman <gnustep_li...@twilightedge.com>: >> >> On May 13, 2020, at 5:52 PM, Andreas Höschler via Discussion list for the >> GNUstep programming environment wrote: >> >>> I could fix the problem under GNUstep by simply commenting out >>> >>> >>> /* if (_firstResponder != v && ![v isKindOfClass: [NSButton >>> class]]) >>> { >>> // Only try to set first responder, when the view wants it. >>> if ([v acceptsFirstResponder] && ![self makeFirstResponder: >>> v]) >>> { >>> return; >>> } >>> } >>> */ >>> >>> Does anything speak against submitting this change into the public tree? >> >> That logic should remain - it's useful for when the clicked responder wants >> first responder status but the current first responder refuses to yield it; >> In that case, it's probably better to return without passing along the >> mouseDown event, otherwise the clicked responder will assume it's active & >> receiving key events, while the current first responder is preventing its >> own deactivation. >> >> That doesn't seem to be the cause of the issue anyway; The different >> behavior between GNUstep & OS X appears to be due to mismatched return >> values of -[NSWindow makeFirstResponder:] - if the passed responder refuses >> first responder status, GNUstep's version returns NO, but OS X's version >> returns YES: >> https://developer.apple.com/documentation/appkit/nswindow/1419366-makefirstresponder?language=objc > > Thank you Josh for pointing this out. This looks like the correct way to go.
I just committed a change in the line of Josh’s reasoning. Andreas, please give it a try. Fred