GNU bug report logs - #61525
29.0.60; delete-frame will raise frames in another virtual desktop

Previous Next

Full log

Message #29 received at 61525 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61525 <at> debbugs.gnu.org, justksqsf <at> gmail.com,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#61525: 29.0.60; delete-frame will raise frames in another
 virtual desktop
Date: Thu, 16 Feb 2023 09:36:46 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Cc: justksqsf <at> gmail.com
>> Date: Wed, 15 Feb 2023 16:41:41 +0100
>> From:  Daniel Martín via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> 
>> Daniel Martín via "Bug reports for GNU Emacs, the Swiss army knife of
>> text editors" <bug-gnu-emacs <at> gnu.org> writes:
>> 
>> >
>> > One downside of removing raise_frame is that, after you press C-x 5 0,
>> > you cannot start typing right away without first focusing on another
>> > Emacs frame manually.  People would consider this a regression from
>> > previous versions and something that doesn't happen on GNU/Linux.
>> >
>> > A possibly better approach could be:
>> >
>> > Once the "other" frame to select is chosen by the code that is just
>> > above in frame.c, call some Obj-C code that extracts the EmacsView and
>> > makes it the first responder:
>> >
>> > EmacsView *view = FRAME_NS_VIEW (frame1);
>> > [self makeFirstResponder:view];
>> >
>> > I haven't tested this, but perhaps this makes the other frame receive
>> > focus without switching desktops in a multi-desktop configuration.
>> 
>> The attached patch avoids the unwanted side effects of raise-frame by
>> making the other frame the key window, instead.  Could you give it a
>> try?
>
> Thanks.
>
>> +void ns_make_frame_key_window (struct frame *f)
>> +{
>> +  [[FRAME_NS_VIEW (f) window] makeKeyWindow];
>> +}

justksqsf <at> gmail.com, please write:

void
ns_make_frame_key_window (struct frame *f)
{
  ...
}

instead.

> Is this new call guaranteed to exist and work well on all the
> supported OS versions where we have the NS build?  I wouldn't want to
> fix this on some systems and break it on others at the same time.

Yes, this seems to exist in GNUstep (meaning that it should exist in an
old Mac OS as well.)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.