discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GUI incompatibility


From: Fred Kiefer
Subject: Re: GUI incompatibility
Date: Thu, 14 May 2020 09:35:47 +0200

> Am 14.05.2020 um 00:53 schrieb Andreas Höschler via Discussion list for the 
> GNUstep programming environment <discuss-gnustep@gnu.org>:
>>> 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?
>> 
>> Just commenting out parts of the code won’t do. As you could probably see 
>> with your own code by adding a log statement in acceptsFirstResponder that 
>> method needs to be called. Other changes to this logic here are welcome, but 
>> they need to address more than one specific issue. Maybe you could provide 
>> more details on what happens on Cocoa?
> 
> On Cocoa this happens.
> 
>> 13/05/20 17:23:40,783 InterfaceBuilder[93679]: <FormTextField: 0x102cd30> 
>> acceptsFirstMouse 1
>> 13/05/20 17:23:40,783 InterfaceBuilder[93679]: <FormTextField: 0x102cd30> 
>> becomeFirstResponder 0
>> 13/05/20 17:23:40,784 InterfaceBuilder[93679]: <FormTextField: 0x102cd30> 
>> mouseDown ..
> 
> So we might want to call acceptsFirstResponder: but not drop out if the 
> answer is NO but call mouseDown: anyway!? This would probably mimic the Cocoa 
> behaviour!


In your Cocoa output acceptsFirstMouse comes before becomeFirstResponder so 
maybe we need to move line 3972 "if (wasKey == YES || [v acceptsFirstMouse: 
theEvent] == YES)“ further up. But what should we do with the result of 
makeFirstResponder just ignore it?And what should we do with 
_lastLeftMouseDownView? At what point should that be cleared? This variable 
gets used for drag or mouse up events later on to make sure these go to the 
same view as the mouse down event. The current way of setting this value just 
before we send the mouse down event to the view seems correct. But why do we 
destroy it?

I hope to find time for a few tests on Cocoa later today or on the weekend.

Fred


reply via email to

[Prev in Thread] Current Thread [Next in Thread]