all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#5482: frame-invisible-p reports nil for iconified frames on w32
@ 2010-01-26 20:37 Lennart Borgman
  2016-06-26  3:56 ` Andrew Hyatt
  0 siblings, 1 reply; 9+ messages in thread
From: Lennart Borgman @ 2010-01-26 20:37 UTC (permalink / raw)
  To: 5482

This problem happens for example under these circumstances:

Create a frame

  (setq my-frame (make-frame))

Iconify it. Then make it first invisible and then visible again:

  (make-frame-invisible my-frame)
  (make-frame-visible my-frame)

The result of checking if it is visible is now nil (should be `iconified'):

  (frame-visible-p my-frame)

This is with a fresh checkout from yesterday.


BTW the implementation of frame-visible-p seems a bit strange to me on
w32. It is easy to check visibility using GetWindowPlacement, but is
this used?







^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#5482: frame-invisible-p reports nil for iconified frames on w32
  2010-01-26 20:37 bug#5482: frame-invisible-p reports nil for iconified frames on w32 Lennart Borgman
@ 2016-06-26  3:56 ` Andrew Hyatt
  2016-06-26 10:18   ` martin rudalics
  0 siblings, 1 reply; 9+ messages in thread
From: Andrew Hyatt @ 2016-06-26  3:56 UTC (permalink / raw)
  To: Lennart Borgman; +Cc: 5482


Lennart Borgman <lennart.borgman@gmail.com> writes:

> This problem happens for example under these circumstances:
>
> Create a frame
>
>   (setq my-frame (make-frame))
>
> Iconify it. Then make it first invisible and then visible again:
>
>   (make-frame-invisible my-frame)
>   (make-frame-visible my-frame)
>
> The result of checking if it is visible is now nil (should be `iconified'):
>
>   (frame-visible-p my-frame)
>
> This is with a fresh checkout from yesterday.
>
>
> BTW the implementation of frame-visible-p seems a bit strange to me on
> w32. It is easy to check visibility using GetWindowPlacement, but is
> this used?

Sorry for the late reply here.  In Emacs 25, the behavior is different,
at least for me in Mac OS X.  Now, when I do (make-frame-visible
my-frame), the frame uniconifies and becomes a normal window again.

Can you (or anyone else) still reproduce this on Windows? 







^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#5482: frame-invisible-p reports nil for iconified frames on w32
  2016-06-26  3:56 ` Andrew Hyatt
@ 2016-06-26 10:18   ` martin rudalics
  2016-06-26 15:58     ` Eli Zaretskii
  0 siblings, 1 reply; 9+ messages in thread
From: martin rudalics @ 2016-06-26 10:18 UTC (permalink / raw)
  To: Andrew Hyatt, Lennart Borgman; +Cc: 5482

[-- Attachment #1: Type: text/plain, Size: 1418 bytes --]

 >> Create a frame
 >>
 >>    (setq my-frame (make-frame))
 >>
 >> Iconify it. Then make it first invisible and then visible again:
 >>
 >>    (make-frame-invisible my-frame)
 >>    (make-frame-visible my-frame)
 >>
 >> The result of checking if it is visible is now nil (should be `iconified'):
 >>
 >>    (frame-visible-p my-frame)
 >>
 >> This is with a fresh checkout from yesterday.
 >>
 >>
 >> BTW the implementation of frame-visible-p seems a bit strange to me on
 >> w32. It is easy to check visibility using GetWindowPlacement, but is
 >> this used?
 >
 > Sorry for the late reply here.  In Emacs 25, the behavior is different,
 > at least for me in Mac OS X.  Now, when I do (make-frame-visible
 > my-frame), the frame uniconifies and becomes a normal window again.

And that's wrong according to the OP.  The frame should stay iconified.
The attached patch would fix this in the OP's sense on Windows but this
would probably have to be fixed in a similar sense on the other
platforms as well and I wouldn't know how to do that in xterm.c where we
have this explicit specification:

/* Make the frame visible (mapped and not iconified).  */

void
x_make_frame_invisible (struct frame *f)

I suppose it can't be done reliably on GNU/Linux and that's why Windows
has to stick to the wrong behavior.

 > Can you (or anyone else) still reproduce this on Windows?

This should be reproducible everywhere.

martin

[-- Attachment #2: w32term.diff --]
[-- Type: text/plain, Size: 767 bytes --]

diff --git a/src/w32term.c b/src/w32term.c
index 14bc52c..a83540b 100644
--- a/src/w32term.c
+++ b/src/w32term.c
@@ -6451,7 +6451,7 @@ struct xim_inst_t
 	 determine the appropriate flag to pass to ShowWindow.  */
       my_show_window (f, FRAME_W32_WINDOW (f),
 		      f->mini_frame ? SW_SHOWNOACTIVATE
-                      : FRAME_ICONIFIED_P (f) ? SW_RESTORE
+                      : FRAME_ICONIFIED_P (f) ? SW_SHOWMINNOACTIVE
 		      : SW_SHOWNORMAL);
     }
 
@@ -6515,7 +6515,7 @@ struct xim_inst_t
      FRAME_SAMPLE_VISIBILITY set this.  So do it by hand,
      and synchronize with the server to make sure we agree.  */
   SET_FRAME_VISIBLE (f, 0);
-  SET_FRAME_ICONIFIED (f, false);
+/**   SET_FRAME_ICONIFIED (f, false); **/
 
   unblock_input ();
 }


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* bug#5482: frame-invisible-p reports nil for iconified frames on w32
  2016-06-26 10:18   ` martin rudalics
@ 2016-06-26 15:58     ` Eli Zaretskii
  2016-06-27  6:22       ` martin rudalics
  0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2016-06-26 15:58 UTC (permalink / raw)
  To: martin rudalics; +Cc: ahyatt, lennart.borgman, 5482

> Date: Sun, 26 Jun 2016 12:18:30 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: 5482@debbugs.gnu.org
> 
>  >> Create a frame
>  >>
>  >>    (setq my-frame (make-frame))
>  >>
>  >> Iconify it. Then make it first invisible and then visible again:
>  >>
>  >>    (make-frame-invisible my-frame)
>  >>    (make-frame-visible my-frame)
>  >>
>  >> The result of checking if it is visible is now nil (should be `iconified'):
>  >>
>  >>    (frame-visible-p my-frame)
>  >>
>  >> This is with a fresh checkout from yesterday.
>  >>
>  >>
>  >> BTW the implementation of frame-visible-p seems a bit strange to me on
>  >> w32. It is easy to check visibility using GetWindowPlacement, but is
>  >> this used?
>  >
>  > Sorry for the late reply here.  In Emacs 25, the behavior is different,
>  > at least for me in Mac OS X.  Now, when I do (make-frame-visible
>  > my-frame), the frame uniconifies and becomes a normal window again.
> 
> And that's wrong according to the OP. The frame should stay iconified.

AFAIU, there are actually 2 issues here: the nil value returned by
frame-visible-p, which is what I see here if frame-visible-p is
invoked immediately after make-frame-visible, i.e. without letting
Emacs enter redisplay; and the fact that the frame becomes a normal
window.

The first issue is expected, since we ask the UI thread to update the
frame's display, and that takes some short time.  In general, one
shouldn't expect the effect of changing frame visibility to be
reflected to Lisp immediately; a call to sit-for is a good idea.

As for the second issue, I disagree that this behavior is wrong,
because it matches the documentation:

  A frame on a graphical display may be “visible”, “invisible”, or
  “iconified”.  If it is visible, its contents are displayed in the usual
		^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  manner.  If it is iconified, its contents are not displayed, but there
  ^^^^^^
  is a little icon somewhere to bring the frame back into view (some
  window managers refer to this state as “minimized” rather than
  “iconified”, but from Emacs’ point of view they are the same thing).  If
  a frame is invisible, it is not displayed at all.

   -- Command: make-frame-visible &optional frame
       This function makes frame FRAME visible.

So I see no reason to fix anything in what make-frame-visible does in
this case.

I could perhaps agree that iconify-frame should have undone the effect
of make-frame-invisible in this use case, though.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#5482: frame-invisible-p reports nil for iconified frames on w32
  2016-06-26 15:58     ` Eli Zaretskii
@ 2016-06-27  6:22       ` martin rudalics
  2016-06-27 15:40         ` Eli Zaretskii
  2018-06-14  0:48         ` Noam Postavsky
  0 siblings, 2 replies; 9+ messages in thread
From: martin rudalics @ 2016-06-27  6:22 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: ahyatt, lennart.borgman, 5482

 > As for the second issue, I disagree that this behavior is wrong,
 > because it matches the documentation:
 >
 >    A frame on a graphical display may be “visible”, “invisible”, or
 >    “iconified”.  If it is visible, its contents are displayed in the usual
 > 		^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 >    manner.  If it is iconified, its contents are not displayed, but there
 >    ^^^^^^
 >    is a little icon somewhere to bring the frame back into view (some
 >    window managers refer to this state as “minimized” rather than
 >    “iconified”, but from Emacs’ point of view they are the same thing).  If
 >    a frame is invisible, it is not displayed at all.
 >
 >     -- Command: make-frame-visible &optional frame
 >         This function makes frame FRAME visible.
 >
 > So I see no reason to fix anything in what make-frame-visible does in
 > this case.

Neither do I.  Emacs implements just a subset of the states and
transitions provided by the Windows API.

 > I could perhaps agree that iconify-frame should have undone the effect
 > of make-frame-invisible in this use case, though.

I see no problems with

(progn
   (setq my-frame (make-frame))
   (make-frame-invisible my-frame)
   (sit-for 1)
   (iconify-frame my-frame)
   (sit-for 1)
   (frame-visible-p my-frame))

Or what did you have in mind?

martin






^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#5482: frame-invisible-p reports nil for iconified frames on w32
  2016-06-27  6:22       ` martin rudalics
@ 2016-06-27 15:40         ` Eli Zaretskii
  2016-06-27 16:56           ` martin rudalics
  2018-06-14  0:48         ` Noam Postavsky
  1 sibling, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2016-06-27 15:40 UTC (permalink / raw)
  To: martin rudalics; +Cc: ahyatt, lennart.borgman, 5482

> Date: Mon, 27 Jun 2016 08:22:06 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: ahyatt@gmail.com, lennart.borgman@gmail.com, 5482@debbugs.gnu.org
> 
>  > I could perhaps agree that iconify-frame should have undone the effect
>  > of make-frame-invisible in this use case, though.
> 
> I see no problems with
> 
> (progn
>    (setq my-frame (make-frame))
>    (make-frame-invisible my-frame)
>    (sit-for 1)
>    (iconify-frame my-frame)
>    (sit-for 1)
>    (frame-visible-p my-frame))
> 
> Or what did you have in mind?

On Windows 7, calling iconify-frame doesn't cause the frame to show
when the mouse pointer hovers above the Emacs icon on the task bar, as
if the frame is still invisible.  No such problem on XP, though.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#5482: frame-invisible-p reports nil for iconified frames on w32
  2016-06-27 15:40         ` Eli Zaretskii
@ 2016-06-27 16:56           ` martin rudalics
  2016-06-28 16:00             ` Eli Zaretskii
  0 siblings, 1 reply; 9+ messages in thread
From: martin rudalics @ 2016-06-27 16:56 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: ahyatt, lennart.borgman, 5482

 > On Windows 7, calling iconify-frame doesn't cause the frame to show
 > when the mouse pointer hovers above the Emacs icon on the task bar, as
 > if the frame is still invisible.  No such problem on XP, though.

Aha.  Windows is getting picky.  Would

   my_show_window (f, FRAME_W32_WINDOW (f), SW_SHOWMINNOACTIVE);

instead of

   SendMessage (FRAME_W32_WINDOW (f), WM_SYSCOMMAND, SC_MINIMIZE, 0);

in x_iconify_frame fix it?

martin





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#5482: frame-invisible-p reports nil for iconified frames on w32
  2016-06-27 16:56           ` martin rudalics
@ 2016-06-28 16:00             ` Eli Zaretskii
  0 siblings, 0 replies; 9+ messages in thread
From: Eli Zaretskii @ 2016-06-28 16:00 UTC (permalink / raw)
  To: martin rudalics; +Cc: ahyatt, lennart.borgman, 5482

> Date: Mon, 27 Jun 2016 18:56:23 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: ahyatt@gmail.com, lennart.borgman@gmail.com, 5482@debbugs.gnu.org
> 
>  > On Windows 7, calling iconify-frame doesn't cause the frame to show
>  > when the mouse pointer hovers above the Emacs icon on the task bar, as
>  > if the frame is still invisible.  No such problem on XP, though.
> 
> Aha.  Windows is getting picky.  Would
> 
>    my_show_window (f, FRAME_W32_WINDOW (f), SW_SHOWMINNOACTIVE);
> 
> instead of
> 
>    SendMessage (FRAME_W32_WINDOW (f), WM_SYSCOMMAND, SC_MINIMIZE, 0);
> 
> in x_iconify_frame fix it?

I don't know enough about this to tell.  (Why SW_SHOWMINNOACTIVE and
not SW_SHOWMINIMIZED?)

But if this seems to fix the issue, feel free to push to master.

Thanks.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#5482: frame-invisible-p reports nil for iconified frames on w32
  2016-06-27  6:22       ` martin rudalics
  2016-06-27 15:40         ` Eli Zaretskii
@ 2018-06-14  0:48         ` Noam Postavsky
  1 sibling, 0 replies; 9+ messages in thread
From: Noam Postavsky @ 2018-06-14  0:48 UTC (permalink / raw)
  To: martin rudalics; +Cc: lennart.borgman, ahyatt, 5482

tags 5482 notabug
close 5482
quit

martin rudalics <rudalics@gmx.at> writes:

>> As for the second issue, I disagree that this behavior is wrong,
>> because it matches the documentation:
>>
>>    A frame on a graphical display may be “visible”, “invisible”, or
>>    “iconified”.  If it is visible, its contents are displayed in the usual
>> 		^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>    manner.

>>     -- Command: make-frame-visible &optional frame
>>         This function makes frame FRAME visible.
>>
>> So I see no reason to fix anything in what make-frame-visible does in
>> this case.
>
> Neither do I.  Emacs implements just a subset of the states and
> transitions provided by the Windows API.

I agree with this as well.  Therefore closing as notabug.

> On Windows 7, calling iconify-frame doesn't cause the frame to show
> when the mouse pointer hovers above the Emacs icon on the task bar, as
> if the frame is still invisible.  No such problem on XP, though.

Couldn't reproduce this on with Emacs 25.3 on Windows 7, even though it
seems Martin's suggested change was never merged.  We could open a new
report if needed, though it seems so minor it's probably not even worth
the trouble.






^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2018-06-14  0:48 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-01-26 20:37 bug#5482: frame-invisible-p reports nil for iconified frames on w32 Lennart Borgman
2016-06-26  3:56 ` Andrew Hyatt
2016-06-26 10:18   ` martin rudalics
2016-06-26 15:58     ` Eli Zaretskii
2016-06-27  6:22       ` martin rudalics
2016-06-27 15:40         ` Eli Zaretskii
2016-06-27 16:56           ` martin rudalics
2016-06-28 16:00             ` Eli Zaretskii
2018-06-14  0:48         ` Noam Postavsky

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.