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#31031: 27.0; (elisp) `Position Parameters', floating-point values Date: Wed, 04 Apr 2018 14:07:45 +0200 Message-ID: <87sh8bw4xa.fsf@gmail.com> References: <5AC3232D.1020107@gmx.at> <874lksy9vy.fsf@gmail.com> <5AC35626.2070700@gmx.at> <877epowjq9.fsf@gmail.com> <5AC48386.8040901@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 1522843573 13286 195.159.176.226 (4 Apr 2018 12:06:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 4 Apr 2018 12:06:13 +0000 (UTC) Cc: 31031@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Apr 04 14:06:08 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 1f3hB2-0003MQ-4L for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Apr 2018 14:06:08 +0200 Original-Received: from localhost ([::1]:53206 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f3hD7-00057U-ML for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Apr 2018 08:08:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42138) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f3hCw-00055L-3x for bug-gnu-emacs@gnu.org; Wed, 04 Apr 2018 08:08:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f3hCs-0005jT-U0 for bug-gnu-emacs@gnu.org; Wed, 04 Apr 2018 08:08:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:58094) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f3hCs-0005jF-PN for bug-gnu-emacs@gnu.org; Wed, 04 Apr 2018 08:08:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1f3hCs-0007XV-H6 for bug-gnu-emacs@gnu.org; Wed, 04 Apr 2018 08:08:02 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Robert Pluim Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 04 Apr 2018 12:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31031 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 31031-submit@debbugs.gnu.org id=B31031.152284367528967 (code B ref 31031); Wed, 04 Apr 2018 12:08:02 +0000 Original-Received: (at 31031) by debbugs.gnu.org; 4 Apr 2018 12:07:55 +0000 Original-Received: from localhost ([127.0.0.1]:37758 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f3hCl-0007X8-0x for submit@debbugs.gnu.org; Wed, 04 Apr 2018 08:07:55 -0400 Original-Received: from mail-wm0-f53.google.com ([74.125.82.53]:37323) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f3hCj-0007Ww-VJ for 31031@debbugs.gnu.org; Wed, 04 Apr 2018 08:07:54 -0400 Original-Received: by mail-wm0-f53.google.com with SMTP id r131so41808752wmb.2 for <31031@debbugs.gnu.org>; Wed, 04 Apr 2018 05:07:53 -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:message-id:mime-version:content-transfer-encoding; bh=rUfaZXjVcobo9lScNESuGkfZTvNpuqTtGvrdZSFo5kE=; b=Vc1mR7I+RwojgQ+PNLHuLQ+vZtArdurKMT11JOeNwfnsCQblfKawsacJd5JImujirl 4tDOq9RKbJhO2t/aaznDqF8W8n7wHY4RnLfZU0z+aV5YM5kmrxsyymCGm3tKqf+CVNvX r0UdQVdDlXP6V2/IpJHRFMv7AqPfs/8HKpSZJs1GpxnnArVYyL9Zvn93BSx55n6Ijc/u ++NBpTmJnBPC+eQDqalUmtV/nJvZlK9/yDtZhYAw5tWmL8ToIn+9ljXTyujPU3l9MtYH mqPrgNgX7Ob6m6zu4uMgPRclQ281W/dYd5+x0Mgr94lcG43X9sgokow2ojP0b1v6WrfR kO8Q== 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:message-id:mime-version :content-transfer-encoding; bh=rUfaZXjVcobo9lScNESuGkfZTvNpuqTtGvrdZSFo5kE=; b=FWUqYR0lty7+qVDZxJEhNVjSouL20yiVkhR67xzbRwV/iCRP/ve+VVuneK0iqtFpxq i5L+nDbxkyfeqmzzqhmfDlDd+RXHMWTAL3KcxtzyvxnYooJqY6jWPYfnlCpljbwcsYxB JYrTMTdr/oaxW2307pHljLPA5hslVlS/LnYXm8vWw4wLG4PjcFLttkJg6Egoi+0Ru6NX wScWirfMpeAY8G1qKd4c09c8ixJFOvIL+sT6mo1QyjTI5zagpP0kO9TtgEs2JSgHM9H8 fECt7Dp65CgGnH0TTGBTX5iTjRlS1+4nUu3j34F9Pf6OEEmT0/nnRDcYDMrJHUBW9gq7 wGHA== X-Gm-Message-State: ALQs6tA3f5dLMQQumLu2sOVSKZ9YoORSrEm7ic/4kiKGYRJkEuwZWXow jOK4SNF8fjweCQXFx4hRl3vIUyC2UWA= X-Google-Smtp-Source: AIpwx4/b7g/wqJZBu2ptTUexqLVzyEgiC7MM+jNLnRFiviRYikH+EBsYGB7CFLWVzUD7Ucf116rJkw== X-Received: by 10.28.190.3 with SMTP id o3mr167715wmf.57.1522843667661; Wed, 04 Apr 2018 05:07:47 -0700 (PDT) Original-Received: from rpluim (vav06-1-78-207-202-134.fbx.proxad.net. [78.207.202.134]) by smtp.gmail.com with ESMTPSA id t8sm3971802wmc.20.2018.04.04.05.07.46 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 04 Apr 2018 05:07:46 -0700 (PDT) Mail-Copies-To: never Gmane-Reply-To-List: yes 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:144882 Archived-At: martin rudalics writes: >>> Can you try fixing that in some consistent manner? You can find the >>> corresponding code in x_calc_absolute_position in xterm.c. BTW, does >>> it work right when you use the "(- POS)" specification? >> >> (modify-frame-parameters nil '((user-position . t) (left . (- 0)))) >> >> gives the same offset effect as >> >> (modify-frame-parameters nil '((user-position . t) (left . 1.0))) > > So we should try fixing (or documenting) the misbehavior of the (- n) > notation first. As noted elsewhere, I think this is a window manager issue. I=CA=BCd expect= those two calls to give the same effect, which is what I see. >> D'oh. Of course, top is the right parameter to use. With that the >> frame switches monitor between top and bottom, so that would imply >> that the same switching should happen for "left". I=CA=BCm undecided so = far >> as to which I think is the "correct" behaviour. > > I'm not sure I understand. Do you mean that when you change the value > of 'left' the frame always stays within the left monitor while when > you change 'top' the frame moves from the upper to the lower monitor > and back? That would be queer. I=CA=BCll have to retest this one, I may have missed a case. >>>> [1] Not completely to the right, but that=CA=BCs a different issue >>> >>> Probably a problem with calculating the decorations. Does >>> (frame-geometry) return "reasonable" values for your frame? >> >> (display-monitor-attributes-list) >> (((name . "XWAYLAND0") (geometry 0 540 3840 2160) (workarea 0 540 3840 >> 2094) (mm-size 350 190) (frames #> rudalics* 0x3d5ce80> # #) >> (source . "Gdk"))) >> >> (modify-frame-parameters nil '((user-position . t) (left . 1.0))) >> >> (frame-geometry) >> ((outer-position 2340 . 1730) (outer-size 1480 . 824) > > Hmm ... 2340 + 1480 gives 3820 which is obviously 20 pixels to the > left of 3840. This clearly went wrong. Did we _ask_ for 2340 or > 2360? That I don=CA=BCt know, I=CA=BCll find out... >> (external-border-size 20 . 20) (outer-border-width . 0) >> (title-bar-size 0 . 70) (menu-bar-external . t) (menu-bar-size 0 . 0) >> (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 0 >> . 0) (internal-border-width . 0)) >> >> (+ 2340 1480) =3D> 3820, + external-border-size? In any case, visually >> the frame is not flush right. > > Do we anywhere add only one 'external-border-size' instead of two? > >> If I correct the visual aspect: >> >> (modify-frame-parameters nil '((left . (+ 2400)))) >> >> (frame-geometry) >> ((outer-position 2380 . 1586) (outer-size 1480 . 824) >> (external-border-size 20 . 20) (outer-border-width . 0) >> (title-bar-size 0 . 70) (menu-bar-external . t) (menu-bar-size 0 . 0) >> (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 0 >> . 0) (internal-border-width . 0)) >> >> which to me says there=CA=BCs a (-20) error for the outer-position at >> least. > > Why did you ask for 2400 and not for 2360? If the position value is > too large the window manager might try to fit the frame onto the > screen. OTOH "correcting" this to 2380 means there are 20 pixels (the > full right external border) missing on the right if not I am missing > something. I asked for 2400 because if I ask for 2360 the frame is not flush right. > BTW is this on a high resolution display? Would/should we scale > external borders on such a display too? Yes, it=CA=BCs high resolution, but 20 pixels seems like more than can be accounted for by scaling. > martin > >> I=CA=BCll take a look at x_calc_absolute_position. I think we=CA=BCre getting a -20 offset back from X somewhere when querying the frame size/position. If I look at this hunk in x_real_pos_and_offsets: #ifdef USE_XCB geom =3D xcb_get_geometry_reply (xcb_conn, geom_cookie, NULL); if (geom) { real_x =3D geom->x; then real_x there is -20 when the frame is flush left. Should we be using gdk/gtk calls to get the window geometry? Robert