From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ryan Prior Newsgroups: gmane.emacs.bugs Subject: bug#21348: bug#21469: bug#21348: 25.0.50; Screen scaling factor >=2 causes menus, tooltips to display in the wrong place Date: Tue, 13 Oct 2015 15:37:48 -0500 Message-ID: References: <86twpvhjxf.fsf@gmail.com> <561D288E.7070803@gmx.at> <561D3DA5.9000801@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1444768846 7418 80.91.229.3 (13 Oct 2015 20:40:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 13 Oct 2015 20:40:46 +0000 (UTC) Cc: 21348@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 13 22:40:33 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zm6N1-0003Ov-AA for geb-bug-gnu-emacs@m.gmane.org; Tue, 13 Oct 2015 22:40:27 +0200 Original-Received: from localhost ([::1]:39245 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zm6N0-0006zm-HJ for geb-bug-gnu-emacs@m.gmane.org; Tue, 13 Oct 2015 16:40:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51889) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zm6Li-0006gm-20 for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2015 16:39:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zm6Le-0007Iw-QF for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2015 16:39:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50138) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zm6Le-0007Ik-FK for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2015 16:39:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Zm6Le-0008Lr-2K for bug-gnu-emacs@gnu.org; Tue, 13 Oct 2015 16:39:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ryan Prior Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Oct 2015 20:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21348 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21348-submit@debbugs.gnu.org id=B21348.144476871132066 (code B ref 21348); Tue, 13 Oct 2015 20:39:01 +0000 Original-Received: (at 21348) by debbugs.gnu.org; 13 Oct 2015 20:38:31 +0000 Original-Received: from localhost ([127.0.0.1]:39109 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zm6L8-0008L7-Vm for submit@debbugs.gnu.org; Tue, 13 Oct 2015 16:38:31 -0400 Original-Received: from mail-yk0-f181.google.com ([209.85.160.181]:32833) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Zm6L6-0008Kz-TY for 21348@debbugs.gnu.org; Tue, 13 Oct 2015 16:38:29 -0400 Original-Received: by ykoo7 with SMTP id o7so28982266yko.0 for <21348@debbugs.gnu.org>; Tue, 13 Oct 2015 13:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=VKuFy5Oxfoiy6jZwQkn66WhtmL1OMZ30amIvaMWnOo0=; b=iXJIa9IqhS9uROpaYAkDgMhs7UgiyuQ4/fblsW2o05V4MB/ALhgXCFuwQx3KosOLPb lwxzQKRF8uTQMM9PdUPAaJ/MxKqiBN9WsM05hCbpn4gRS90vXq4Ubz64i8tL+VE2DBvv zl/SeXNT5WhzY9UPHnc5T79O+XDKS8ZbUgX3fHm21C0HtLfVCckokicuW6BhVKcDL/me yHRTnvXDeO/Ay2waBg7zcyvnjleE8ORMvyRIVm7CI8Fvw8j1gzPl2OhXJ7IyYtLf/idA mrHKDlGFXu8RN6YVqx3LIi9+qNafAFLpD54gvaWgUu+KpIKyNXXMqELKjNbTQgArXwPW gCVQ== X-Received: by 10.13.217.66 with SMTP id b63mr25365863ywe.152.1444768708200; Tue, 13 Oct 2015 13:38:28 -0700 (PDT) Original-Received: by 10.37.87.193 with HTTP; Tue, 13 Oct 2015 13:37:48 -0700 (PDT) In-Reply-To: <561D3DA5.9000801@gmx.at> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x 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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:107585 Archived-At: On Tue, Oct 13, 2015 at 12:21 PM, martin rudalics wrote: > Can you try again with the > =E2=80=98user-position=E2=80=99 frame parameter non-nil? The behavior is identical. > You mean on a subsequent attempt the frame is flushed left or still at > position 20. What happens when you try something similar with the =E2=80= =98top=E2=80=99 > parameter? The frame is never flush left except during brief flash. Immediately afterward, and subsequent to each additional call, the actual frame position is offset by 20 pixels. This is true for top just as it is for left. > Does that mean the offset of 20 pixels appears with scaling turned off > and on? Not quite. With scaling at 2x, the offset is 20 pixels. With scaling at 1x, the offset is 10 pixels. > So the window manager probably constrains frame positioning. What > happens with a frame larger than the screen size? This question opened a can of worms. The answer, on Ubuntu Trusty with Unity (Compiz) window manager, is that it depends on which virtual desktop you are on. I have four virtual desktops laid out in a 2x2 grid, which I'll refer to clockwise like so: [1][2] [4][3] On desktop 1, it behaves the same as for a frame which is smaller than the screen size and not flush with the right screen edge: offset of (10*scale) pixels when positioning left or top, doesn't appear to "stick" to anything. On desktop 2, positioning top behaves the same as desktop 1, but positioning left results in a frame flush with the left screen edge. This is not true of frames smaller than the screen size, which I previously tested on each virtual desktop and displayed consistent behavior. On desktop 4, we see a symmetric behavior where positioning left behaves the same as desktop 1, but positioning top results in a frame flush with the screen top edge. On desktop 3, positioning both left and top results in a frame flush with the respective screen edge, and I observed an additional curious behavior. Each call to set the top position also decreases the left position by a small amount, if the number of pixels specified as the top position is small. In the range of 10-30, it budged the left side; in the range of 100-500, it didn't. When I came to write up my results, I decided to try to pin down exactly where the cut-off was between values which would or wouldn't budge the frame to the left, so I restarted emacs and set about trying to reproduce it. But I can't. This time around, a frame larger than the screen behaves in all ways as I described for desktop 1. This test could be exercising some little-tested code paths in Emacs, Unity, or both. As before, I appreciate any assistance in corroborating and analyzing this information. > And does =E2=80=98set-mouse-absolute-pixel-position=E2=80=99 work normall= y? In fact, mouse-set-absolute-pixel-position works flawlessly as expected. If I set the frame left position to 0 and the mouse x position to (10*scale), they line up precisely. Similarly, I can set the mouse position to (0,0) with no problem. Ryan