From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: David Reitter <reitter@cmu.edu>
Cc: 3303@emacsbugs.donarmstrong.com,
Chong Yidong <cyd@stupidchicken.com>,
Adrian Robert <adrian.b.robert@gmail.com>
Subject: bug#3303: delete-frame raises old (invisible) frame
Date: Mon, 25 May 2009 11:17:17 -0400 [thread overview]
Message-ID: <jwv1vqdrzol.fsf-monnier+emacsbugreports@gnu.org> (raw)
In-Reply-To: <513F6DDF-F57F-4C8E-A2ED-C2163183BFF0@cmu.edu> (David Reitter's message of "Thu, 21 May 2009 23:57:08 -0400")
> OK, I think I have a set of fixes now for this bug.
Good, thanks.
> PS.: I agree with the proposed change to after-make-frame-functions (not
> selecting the frame immediately), but this doesn't relate to the bug at
> hand. Also, I don't know why the modeline isn't updated.
Agreed, this is a separate problem.
I'm not familiar enough with the NS code to judge if the patch is OK,
but here are some comments:
> frame.c:
> Fraise_frame: do not make invisible frames visible (Stefan Monnier).
This is not OK for 23.1. It might be good to try it for 23.2.
Also I think your other changes should make it unnecessary for the
problem we're trying to fix.
> nsterm.m:
> ns_raise_frame(): only raise frame if visible.
Since you say that "invisible" is implemented by lowering the window
below the background, this seems like a plain bug-fix, yes.
> x_make_frame_visible(): move frame to front rather than calling
> ns_raise_frame().
Sounds right.
> keyDown: do not swallow events that aren't re-sent if frame isn't
> key window.
If you say so.
> drawRect: do not set visibility/iconified flags because drawRect may be
> called by NSView even if the frame is hidden.
Do you happen to know why/when NSView might be called even for a frame
that's not visible?
> nsfns.m:
> Fx_create_frame(): follow other ports in determining visibility; default to
> t. Ensure async_visible is set.
Sounds good.
> + f->async_visible=1;
[...]
> + f->async_visible=0;
Please put spaces around infix operators (like `=' above).
> @@ -895,9 +895,14 @@ ns_raise_frame (struct frame *f)
> {
> NSView *view = FRAME_NS_VIEW (f);
> check_ns ();
> - BLOCK_INPUT;
> - [[view window] makeKeyAndOrderFront: NSApp];
> - UNBLOCK_INPUT;
> +
> + FRAME_SAMPLE_VISIBILITY (f);
> + if (FRAME_VISIBLE_P (f))
> + {
> + BLOCK_INPUT;
> + [[view window] makeKeyAndOrderFront: NSApp];
> + UNBLOCK_INPUT;
> + }
> }
Shouldn't we BLOCK_INPUT around the whole thing, just in case
async_visible gets changed at the wrong time? It probably
doesn't matter.
> {
> NSTRACE (x_make_frame_visible);
> + NSView *view = FRAME_NS_VIEW (f);
> /* XXX: at some points in past this was not needed, as the only place
> that
> called this (frame.c:Fraise_frame ()) also called raise_lower;
> if this ends up the case again, comment this out again. */
> if (!FRAME_VISIBLE_P (f))
> - ns_raise_frame (f);
> + {
> + BLOCK_INPUT;
> + [[view window] makeKeyAndOrderFront: NSApp];
> + UNBLOCK_INPUT;
> + }
> + f->async_visible = 1;
> }
I think I'd prefer:
if (!FRAME_VISIBLE_P (f))
+ {
+ f->async_visible = 1;
ns_raise_frame (f);
+ }
> @@ -5466,8 +5477,6 @@ extern void update_window_cursor (struct window *w,
> int on);
> ns_clear_frame_area (emacsframe, x, y, width, height);
> expose_frame (emacsframe, x, y, width, height);
> - emacsframe->async_visible = 1;
> - emacsframe->async_iconified = 0;
> }
In this kind of change, it's often good to keep the old code commented
out, with a comment explaining why it was removed (and ideally why it
was there before as well).
Stefan
next prev parent reply other threads:[~2009-05-25 15:17 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-22 3:57 bug#3303: delete-frame raises old (invisible) frame David Reitter
2009-05-25 15:17 ` Stefan Monnier [this message]
2009-05-26 18:20 ` David Reitter
2009-05-26 19:37 ` Stefan Monnier
2009-05-26 20:15 ` David Reitter
2009-05-26 21:30 ` Stefan Monnier
2009-05-27 4:51 ` Adrian Robert
2009-05-27 14:36 ` Stefan Monnier
2009-06-01 9:37 ` Adrian Robert
2009-05-27 15:28 ` David Reitter
-- strict thread matches above, loose matches on Subject: below --
2009-05-16 19:28 Chong Yidong
2009-05-17 2:55 ` David Reitter
2009-05-16 1:09 David Reitter
2009-05-17 19:06 ` Stefan Monnier
2009-05-17 19:12 ` David Reitter
2009-05-17 20:43 ` Stefan Monnier
2009-05-17 22:27 ` Lennart Borgman
2009-05-18 3:26 ` Stefan Monnier
2009-05-18 1:16 ` Adrian Robert
2009-05-18 3:33 ` Stefan Monnier
2009-05-18 8:05 ` Adrian Robert
2009-05-18 15:08 ` David Reitter
2009-05-18 20:12 ` Stefan Monnier
2009-05-18 23:00 ` David Reitter
2009-05-19 2:46 ` Stefan Monnier
2009-05-19 2:56 ` David Reitter
2009-05-19 3:09 ` Stefan Monnier
2009-05-19 3:15 ` David Reitter
2009-05-19 8:20 ` YAMAMOTO Mitsuharu
2009-05-19 14:30 ` Stefan Monnier
2009-05-20 2:07 ` David Reitter
2009-05-19 0:58 ` YAMAMOTO Mitsuharu
2009-05-18 8:19 ` YAMAMOTO Mitsuharu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwv1vqdrzol.fsf-monnier+emacsbugreports@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=3303@emacsbugs.donarmstrong.com \
--cc=adrian.b.robert@gmail.com \
--cc=cyd@stupidchicken.com \
--cc=reitter@cmu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).