[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 00:19:04 +0200 |
> Am 13.05.2020 um 23:52 schrieb Andreas Höschler <ahoesch@smartsoft.de>:
>
> I understand the idea behind this part
>
> if (_firstResponder != v && ![v isKindOfClass: [NSButton class]])
> {
> // Only try to set first responder, when the view wants it.
> if ([v acceptsFirstResponder] && ![self makeFirstResponder:
> v])
> {
> NSLog(@"Leaving early");
> return;
> }
> }
>
> but would suggest that this is not entirely correct. My FormTextField refuses
> to become first responder on purpose but nevertheless relies on seeing a
> mouseDown: call. I use that to activate an inspector. At another place in the
> code this mouseDown: is needed to initiate a drag operation to drag the gui
> element around. Cocoa does this correctly IMHO (sends the mouseDown:).
>
> 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? Maybe the order of things is wrong?
Fred
- GUI incompatibility, Andreas Höschler, 2020/05/13
- Re: GUI incompatibility, Josh Freeman, 2020/05/14
- Re: GUI incompatibility, Fred Kiefer, 2020/05/14
- Re: GUI incompatibility, Fred Kiefer, 2020/05/14
- Re: GUI incompatibility, Andreas Höschler, 2020/05/15