GNU bug report logs - #16300
24.3.50; 'M-<F10>' doesn't work always

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: martin rudalics <rudalics <at> gmx.at>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#16300: closed (24.3.50; 'M-<F10>' doesn't work always)
Date: Sat, 04 Jan 2014 13:44:03 +0000

[Message part 1 (text/plain, inline)]

Your message dated Sat, 04 Jan 2014 14:43:33 +0100
with message-id <52C81005.8040700 <at> gmx.at>
and subject line Re: bug#16300: 24.3.50; 'M-<F10>' doesn't work always
has caused the debbugs.gnu.org bug report #16300,
regarding 24.3.50; 'M-<F10>' doesn't work always
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
16300: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16300
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; 'M-<F10>' doesn't work always
Date: Mon, 30 Dec 2013 13:02:01 +0100

Recipe from "emacs -Q":
  M-<F10> M-<F10> M-<F10>

The first time 'M-<F10>' is typed the emacs frame is maximized (OK), the
second time it is un-maximized (OK), but the third time nothing happens (it
should be maximized again).


In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-12-29 on LEG570
Bzr revision: 115804 jan.h.d <at> swipnet.se-20131229131709-3xodjuaj5k14kpev
Windowing system distributor `Microsoft Corp.', version 6.3.9600
Configured using:
 `configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'

-- 
Dani Moncayo

[Message part 3 (message/rfc822, inline)]

From: martin rudalics <rudalics <at> gmx.at>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 16300-done <at> debbugs.gnu.org
Subject: Re: bug#16300: 24.3.50; 'M-<F10>' doesn't work always
Date: Sat, 04 Jan 2014 14:43:33 +0100

> It seems fixed, indeed.

The current code still doesn't catch all possible transitions.  For
example, a FULLSCREEN_HEIGHT followed by two M-<F10>s will get you a
normalized window which is arguable not TRT but catching this without
introducing additional states seems hardly possible.  Here I do

(defun toggle-full-height ()
  (interactive)
  (if (eq (frame-parameter nil 'fullscreen) 'fullheight)
      (set-frame-parameter nil 'fullscreen 'fullnone)
    (set-frame-parameter nil 'fullscreen 'fullheight)))

which IMO is the best way to use the FULLHEIGHT feature.

I'll close this bug.

> And BTW, I don't know if it's due to this change, but I can't
> reproduce the bug #14239 anymore with the current trunk.

The old code used SetWindowPos which according to

http://msdn.microsoft.com/en-us/library/windows/desktop/ms632611%28v=vs.85%29.aspx

should not be used:

  The coordinates used in a WINDOWPLACEMENT structure should be used
  only by the GetWindowPlacement and SetWindowPlacement
  functions. Passing workspace coordinates to functions which expect
  screen coordinates (such as SetWindowPos) will result in the window
  appearing in the wrong location. For example, if the taskbar is at the
  top of the screen, saving window coordinates using GetWindowPlacement
  and restoring them using SetWindowPos causes the window to appear to
  "creep" up the screen.

> So it could
> be closed as well.

Please do that.

martin

Previous Next

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