From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Robert Pluim Newsgroups: gmane.emacs.bugs 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 Message-ID: <87zhzn0w1y.fsf@gmail.com> References: <5B2B50C8.2090600@gmx.at> <87zhzo3083.fsf@gmail.com> <5B2CB996.4060606@gmx.at> <877emr2hmf.fsf@gmail.com> <5B2CE8F0.8070702@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1529676447 27133 195.159.176.226 (22 Jun 2018 14:07:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 22 Jun 2018 14:07:27 +0000 (UTC) Cc: 31920@debbugs.gnu.org, Jonathan Kyle Mitchell To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jun 22 16:07:23 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fWMig-0006wd-Ok for geb-bug-gnu-emacs@m.gmane.org; Fri, 22 Jun 2018 16:07:22 +0200 Original-Received: from localhost ([::1]:34243 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fWMkm-0003aQ-9H for geb-bug-gnu-emacs@m.gmane.org; Fri, 22 Jun 2018 10:09:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33988) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fWMSw-0005kZ-9Y for bug-gnu-emacs@gnu.org; Fri, 22 Jun 2018 09:51:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fWMSt-0008Gd-1p for bug-gnu-emacs@gnu.org; Fri, 22 Jun 2018 09:51:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51882) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fWMSs-0008GQ-UA for bug-gnu-emacs@gnu.org; Fri, 22 Jun 2018 09:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fWMSs-0001rE-KH for bug-gnu-emacs@gnu.org; Fri, 22 Jun 2018 09:51:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Robert Pluim Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Jun 2018 13:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31920 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 31920-submit@debbugs.gnu.org id=B31920.15296754607132 (code B ref 31920); Fri, 22 Jun 2018 13:51:02 +0000 Original-Received: (at 31920) by debbugs.gnu.org; 22 Jun 2018 13:51:00 +0000 Original-Received: from localhost ([127.0.0.1]:59779 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fWMSp-0001qx-Nr for submit@debbugs.gnu.org; Fri, 22 Jun 2018 09:51:00 -0400 Original-Received: from mail-wm0-f43.google.com ([74.125.82.43]:54840) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fWMSn-0001qj-6U for 31920@debbugs.gnu.org; Fri, 22 Jun 2018 09:50:57 -0400 Original-Received: by mail-wm0-f43.google.com with SMTP id o13-v6so2323001wmf.4 for <31920@debbugs.gnu.org>; Fri, 22 Jun 2018 06:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:mail-copies-to:gmane-reply-to-list :date:in-reply-to:message-id:mime-version:content-transfer-encoding; bh=/61i1/Ulr7nZJMlurp0GWfY/tZRjSzwKES0nvMBo61g=; b=hSMmWzk3g03QKORSLca5UFn0Fvr84aIVz/Z7sxlGC5wxWXvBQLbxJl4Y6sJr0aH4lD flp/mc9w3O2bI7+Uec3D/c+M1x4xHb4sOXlbNnxZTX/mMLmxIzUasuF2jYhOM0v/W8bv dhBau/qp0nlCr5dOsjXhzZtUCW7f+uGZm/GHSTuM+2d5VOVmE9TIoKvC7gwv2KjUjATC VIUBE9pMxscZtUVffWTtoaoSQqm6eOiZ9bPGkzmrMRfDJLAQwoPugq7RaQI6dM+qtd6k qNNl/XZu1MGU3arhssdUkY2pVVR3HPnJLjmF7dThpATEPytBGZEyEf2UMywKMT+IAlE1 tTvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:mail-copies-to :gmane-reply-to-list:date:in-reply-to:message-id:mime-version :content-transfer-encoding; bh=/61i1/Ulr7nZJMlurp0GWfY/tZRjSzwKES0nvMBo61g=; b=UGqlvi+2yfVw95WHeED4pYiToMcrkTwaozsUfRyDH8yCC2bEA6TVrPVVLa/RyXE80D Hr6F7OPyVRXf7yEVwNENwcXM0cnlKqiOkuMbwzqD54UARtsVI1g97mTS2GOgTa5hQRqU ttDNMELGWOftBop0UzjqlPf55JDIq1k77NjpJKCK72K0k1JPFlCZpXNNLKMs2qlr3v0Y PN1k9A89r59AvAvkjjwsEvGcIAv/lQK6nHQGW0lyJY1mg7ML2iS22x6RWDcgxZRYmMg3 ZvAfSao4BuNWMzJHglMJ1D34CDdVCOQRXEO1Puf9HmmAvn9/VIl9RN2MKxqD+T22flVR 2sNQ== X-Gm-Message-State: APt69E3IsZ1EApni67c3Z32qECvh/qbfhzi2U7hJqafVG9n+Q/rItmj9 JIgmcGA0MzsAEXtEH4oR3Bk= X-Google-Smtp-Source: ADUXVKJe927s7ZK9P7L/LDL72lF33KLX+smaO6JHEc7X0rT1gybjlmnZ9cN6UMlr6vKnblxTalYSNg== X-Received: by 2002:a1c:387:: with SMTP id 129-v6mr1826242wmd.53.1529675451131; Fri, 22 Jun 2018 06:50:51 -0700 (PDT) Original-Received: from rpluim-ubuntu ([149.5.228.1]) by smtp.gmail.com with ESMTPSA id 11-v6sm1770090wmd.35.2018.06.22.06.50.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jun 2018 06:50:50 -0700 (PDT) Mail-Copies-To: never Gmane-Reply-To-List: yes In-Reply-To: <5B2CE8F0.8070702@gmx.at> (martin rudalics's message of "Fri, 22 Jun 2018 14:17:52 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:147741 Archived-At: martin rudalics writes: >> Which ends up calling frameset--restore-frame, so the problem is elsewhe= re. > > 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 =3D 902, > y =3D 18, > cx =3D 0, > cy =3D 0, > > and Windows gets back to me with a WM_MOVE for (0, 0) - the values > offered by GetWindowRect being > > left =3D 0, > top =3D 0, > right =3D 680, > bottom =3D 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=CA=BCs similar to what I=CA=BCm 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=CA=BCm going to have to break o= ut >> 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=CA=BCt pass fullscreen to modify-frame-parameters" (it=CA=BCs 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=CA=BCre 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=CA=BCm 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=CA=BCm 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))))) =20 -(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 =20 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))) =20 + (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