Re: GUI incompatibility

[Fred Kiefer]

> Am 14.05.2020 um 13:14 schrieb Fred Kiefer <fredkiefer@gmx.de>:
> 
>> Am 14.05.2020 um 12:22 schrieb Josh Freeman <gnustep_lists@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