unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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







  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).