all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Robert Pluim <rpluim@gmail.com>
To: martin rudalics <rudalics@gmx.at>
Cc: 31920@debbugs.gnu.org,
	Jonathan Kyle Mitchell <kyle@jonathanmitchell.org>
Subject: bug#31920: 26.1; frame appears in wrong part of desktop after restoring frameset from fullscreen
Date: Fri, 22 Jun 2018 15:50:49 +0200	[thread overview]
Message-ID: <87zhzn0w1y.fsf@gmail.com> (raw)
In-Reply-To: <5B2CE8F0.8070702@gmx.at> (martin rudalics's message of "Fri, 22 Jun 2018 14:17:52 +0200")

martin rudalics <rudalics@gmx.at> writes:

>> Which ends up calling frameset--restore-frame, so the problem is elsewhere.
>
> Aha.  I have no idea how to debug these cl-forms so I usually end up
> in some sort of nirvana.  On Windows I call WM_EMACS_SETWINDOWPOS (in
> my_set_window_pos) with
>
>   x = 902,
>   y = 18,
>   cx = 0,
>   cy = 0,
>
> and Windows gets back to me with a WM_MOVE for (0, 0) - the values
> offered by GetWindowRect being
>
>   left = 0,
>   top = 0,
>   right = 680,
>   bottom = 658
>
> I have no idea what to learn from this: (902, 18) is the correct
> request and I see no intervening action from there until Windows
> returns (0, 0).
>

Thatʼs similar to what Iʼm seeing. gtk_window_move is called with the
right parameters, but the frame ends up in the wrong place.

>> The code that causes the frame to be restored in the wrong place is
>> this:
>>
>>      (modify-frame-parameters frame
>> 			     (if (eq (frame-parameter frame 'fullscreen) fullscreen)
>> 				 ;; Workaround for bug#14949
>> 				 (assq-delete-all 'fullscreen filtered-cfg)
>> 			       filtered-cfg))
>>
>> in framset--restore-frame, which means Iʼm going to have to break out
>> gdb and/or printf.
>
> And removing the special fullsreen handling doesn't change anything?
> Maybe we _should_ do something special when a fullscreen frame is
> restored to a non-fullscreen one.

If I understand that code, it says "if the old and new fullscreen
states are the same, donʼt pass fullscreen to modify-frame-parameters"
(itʼs Friday afternoon, I may be wrong, and the fullscreen variable
there has an unhelpful name :-) )

> Basically, Emacs has been doing something inherently wrong all the
> time: It asks to resize a frame while that frame is in fullscreen (or
> maximized) state.  The correct interpretation on behalf of the window
> manager would be to store the new sizes and apply them when the frame
> is returned to its normal (non-fullscreen/non-maximized) state, IMHO.
> For some reason, the approach chosen by Emacs has worked so I never
> tried to fiddle with it.  But maybe it bites us this time.

So youʼre saying we should un-maximize, and then set the frame size
afterwards? The patch below tries that, it works for me, although it
does of course cause the frame to resize and then move in two steps.

>>(Iʼm surprised Eli is seeing this on MS-Windows
>> though, I thought the low-level frame implementation was completely
>> separate)
>
> I see this on Windows too.  Normally, buggy behavior consistent across
> platforms is an asset.  For some reason, this doesn't apply here yet.

It turns our that most of the code is common, only the implementations
of things like x_set_offset and x_calc_absolute_position are
platform-specific. Iʼm still surprised they share the same bugs.

Robert

diff --git i/lisp/frame.el w/lisp/frame.el
index 29c31f41cb..a58fad6481 100644
--- i/lisp/frame.el
+++ w/lisp/frame.el
@@ -2413,7 +2413,7 @@ toggle-frame-maximized
      (t
       (set-frame-parameter nil 'fullscreen 'maximized)))))
 
-(defun toggle-frame-fullscreen ()
+(defun toggle-frame-fullscreen (&optional frame)
   "Toggle fullscreen state of selected frame.
 Make selected frame fullscreen or restore its previous size if it
 is already fullscreen.
@@ -2431,14 +2431,14 @@ toggle-frame-fullscreen
 
 See also `toggle-frame-maximized'."
   (interactive)
-  (let ((fullscreen (frame-parameter nil 'fullscreen)))
+  (let ((fullscreen (frame-parameter frame 'fullscreen)))
     (if (memq fullscreen '(fullscreen fullboth))
-	(let ((fullscreen-restore (frame-parameter nil 'fullscreen-restore)))
+	(let ((fullscreen-restore (frame-parameter frame 'fullscreen-restore)))
 	  (if (memq fullscreen-restore '(maximized fullheight fullwidth))
-	      (set-frame-parameter nil 'fullscreen fullscreen-restore)
-	    (set-frame-parameter nil 'fullscreen nil)))
+	      (set-frame-parameter frame 'fullscreen fullscreen-restore)
+	    (set-frame-parameter frame 'fullscreen nil)))
       (modify-frame-parameters
-       nil `((fullscreen . fullboth) (fullscreen-restore . ,fullscreen))))
+       frame `((fullscreen . fullboth) (fullscreen-restore . ,fullscreen))))
     ;; Manipulating a frame without waiting for the fullscreen
     ;; animation to complete can cause a crash, or other unexpected
     ;; behavior, on macOS (bug#28496).
diff --git i/lisp/frameset.el w/lisp/frameset.el
index 0e3363d7ae..ffbf6722a7 100644
--- i/lisp/frameset.el
+++ w/lisp/frameset.el
@@ -1085,6 +1085,11 @@ frameset--restore-frame
       (when (frame-live-p parent-frame)
         (set-frame-parameter frame 'parent-frame parent-frame)))
 
+    (let ((old-fullscreen (frame-parameter frame 'fullscreen)))
+      (and (not (eq old-fullscreen fullscreen))
+           (memq old-fullscreen '(fullscreen fullboth))
+           (not fullscreen)
+           (toggle-frame-fullscreen frame)))
     (modify-frame-parameters frame
 			     (if (eq (frame-parameter frame 'fullscreen) fullscreen)
 				 ;; Workaround for bug#14949





  reply	other threads:[~2018-06-22 13:50 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-21  3:12 bug#31920: 26.1; frame appears in wrong part of desktop after restoring frameset from fullscreen Jonathan Kyle Mitchell
2018-06-21  7:16 ` martin rudalics
2018-06-21 10:25   ` Robert Pluim
2018-06-22  8:55     ` martin rudalics
2018-06-22 11:19       ` Robert Pluim
2018-06-22 12:17         ` martin rudalics
2018-06-22 13:50           ` Robert Pluim [this message]
2018-06-23  8:40             ` martin rudalics
2018-06-27  9:07               ` Robert Pluim
2018-06-28  8:03                 ` martin rudalics
2019-07-01  6:08             ` Spenser Truex
2018-06-21 15:54   ` Eli Zaretskii
2018-06-22  8:55     ` martin rudalics

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zhzn0w1y.fsf@gmail.com \
    --to=rpluim@gmail.com \
    --cc=31920@debbugs.gnu.org \
    --cc=kyle@jonathanmitchell.org \
    --cc=rudalics@gmx.at \
    /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 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.