From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics 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: Wed, 14 Oct 2015 10:49:47 +0200 Message-ID: <561E172B.8010500@gmx.at> 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; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1444812705 18631 80.91.229.3 (14 Oct 2015 08:51:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Oct 2015 08:51:45 +0000 (UTC) Cc: 21348@debbugs.gnu.org To: Ryan Prior Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Oct 14 10:51:34 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 1ZmHmT-0006iO-H2 for geb-bug-gnu-emacs@m.gmane.org; Wed, 14 Oct 2015 10:51:29 +0200 Original-Received: from localhost ([::1]:41200 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmHmS-0003Kc-Qd for geb-bug-gnu-emacs@m.gmane.org; Wed, 14 Oct 2015 04:51:28 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37110) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmHlA-00037V-CW for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2015 04:50:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZmHl6-0008BB-2a for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2015 04:50:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50496) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmHl5-0008B3-VE for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2015 04:50:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZmHl5-0008CT-C7 for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2015 04:50:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 14 Oct 2015 08:50:03 +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.144481259931507 (code B ref 21348); Wed, 14 Oct 2015 08:50:03 +0000 Original-Received: (at 21348) by debbugs.gnu.org; 14 Oct 2015 08:49:59 +0000 Original-Received: from localhost ([127.0.0.1]:39467 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZmHl0-0008C6-9s for submit@debbugs.gnu.org; Wed, 14 Oct 2015 04:49:58 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:64802) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZmHkw-0008Bv-63 for 21348@debbugs.gnu.org; Wed, 14 Oct 2015 04:49:54 -0400 Original-Received: from [62.47.255.84] ([62.47.255.84]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LhSfM-1aQ2PQ2vaa-00mZVr; Wed, 14 Oct 2015 10:49:52 +0200 In-Reply-To: X-Provags-ID: V03:K0:VLLikWYSf5m2qQ/qsSYCDTR7J/rH/72Czg1jUS/pomWi928ho0K N1jSVtVvf4E2R9bcWoxnk9o4y/xf87ELGDsQldZuLOHuW9ec3aHaJ+zqpJduZcIFR288X7k lYy1S32md7L4IRifEh+WI4OjZNyDURCYMD8St+Vt9teUxCugccbIbsPaJY5ACQNF/Zl8hfe ZKQUTphFERfm5QzZ9Fq7Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:r+OfZENUmKg=:2Ob6snnnn7kts63IXlK2aV PHUXGYsM4kZLDVsJz72iLUTrahYeIGvOzbjju6jCWKW7AwbAqarn7bchc3Pq7LCi3qVtkEajS kSAM6Y4HA9ZaKkXpldVXljB625oI2F8qwB0zQQZT3SEm5Jio48UKiMVOC2elhv4jJnCW4Ruog PE4b11V8C/cPVOSUs4AC42lZ+pCXsgBT/J5b4t4I/KltuRDVmadG0mD7etG43rT+8PFa08/ES 5zBhixyBTbvQpFne01iu9FZcXCkrruMl7O9kv01GscrHj5+It29q7ZEgIpI8EYQMI6EMnmHSK GGQvUsUMP2iXZMK/4qFDI8TNZO8+UK2b2AUerQ8J8p0X6akmuHrwTKBC+csnWqHQJK/wc5h89 vEl6FWg0lGRrBsOgSUSAko7+yeCdatbK6axFN4PBPFbXmNAc5gRhuWRemHa+05kSWFU5JhYpG 37Rg8yltFoD8vxoAdCdEu0PYUr575WEzYt3nFDVUNuUzw0gSe64qs8aBRku0uoL1CFdFye4Qn 5L/LC/y5tUKAfAifZKMyUTPNHl4MM4UcHGJhjtdiwhThDDzQzeYDLLYa1rwf2VovSpUxlpnY8 MDte6OFtnENrNpoD9EfzjBote/R8Di1y2lf1aTXD5PWyNbuQwpgZnxOuvVI8Sa/xK9ThOOw9E NolbYVCHzXW9OgJpFz4VdnrGP/TqvFlxp+9ZpBTuWAjswNx+l17VV6OnDZsVgn1DKq/5rNzH4 e/9RVEQOZ1ERydWehLsc7pwCcqq5Zn4CpWOJwKdio1/PQ+1BppwGks3YXR+byz6PHcmjSZrT 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:107598 Archived-At: >> Can you try again with the >> =E2=80=98user-position=E2=80=99 frame parameter non-nil? > > The behavior is identical. So Unity seems to ignore =E2=80=98user-position=E2=80=99. Can you manual= ly move (mouse-drag) the frame to the left edge? Did you ever try to tweak the window placement settings in the Compiz Setting Manager? >> You mean on a subsequent attempt the frame is flushed left or still a= t >> 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. I could imagine Unity to not allow the frame enter a 20 pixels zone if there's some launcher or panel there. But why should it move a frame from position 500 to 520? That simply doesn't make sense. BTW, does maximizing the frame horizontally work? What does evaluating (set-frame-parameter nil 'fullscreen 'fullwidth) give? >> Does that mean the offset of 20 pixels appears with scaling turned of= f >> and on? > > Not quite. With scaling at 2x, the offset is 20 pixels. With scaling > at 1x, the offset is 10 pixels. And with scalings 1.5, 2.5 and 3 you consistently get 15, 25 and 30? If so then we can conclude that the frame position does not scale with the x-coordinate Emacs supplies but shifts by the scale factor times ten. > 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. So it can't go more to the left or upwards due to the 10*scale restriction, I suppose. > 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. You mean that a large frame on desktop 2 gets flushed left, a smaller one gets still set off at the 10*scale position. > 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. Sounds consistent. > 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. In all these calls did you also specify a left position or did you only specify the top position? > 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. That is the behavior on desktop 4 is the same as the behavior on desktop 1: A 10*scale pixel zone on the left and the top are left free? > This test could be exercising some little-tested code paths in Emacs, > Unity, or both. Apart from occasional specifications like (0, 0) or a user supplied position, Emacs never tries to enforce a particular frame position. Also, Emacs nowhere samples the screen size in order to get a fitting initial size of the frame. The default size of the initial frame is 80x35 characters, hardcoded somewhere in frame.c. So all this positioning stuff should be in Unity. How they could possibly have coded such a thing is a mystery to me. >> And does =E2=80=98set-mouse-absolute-pixel-position=E2=80=99 work nor= mally? > > 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. OK. One problem less to care about. > Similarly, I can set > the mouse position to (0,0) with no problem. =E2=80=98set-mouse-absolute-pixel-position=E2=80=99 operates on the "defa= ult root window" of the selected frame's display. Does =E2=80=98set-mouse-pixel-position=E2=80=99 also work as expected? For ex= ample, does (set-mouse-pixel-position (selected-frame) 0 0) correctly move the mouse pointer to a position right under the start of the menu or tool bar? martin