discuss-gnustep
[Top][All Lists]
Advanced

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

Re: GUI incompatibility


From: Andreas Höschler
Subject: Re: GUI incompatibility
Date: Thu, 14 May 2020 10:16:53 +0200

Hi Fred,

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.

That would be great. For now I have done

              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;
                    }
                }


This at least works for me though there might be a better solution.

Best wishes,

 Andreas


reply via email to

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