From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Brian Zwahr Newsgroups: gmane.emacs.bugs Subject: bug#31880: 26.1; VC mode line popup when clicked is off screen Date: Wed, 20 Jun 2018 15:15:03 -0500 Message-ID: References: <5B28ADFC.4060704@gmx.at> <380133793885a54af49bbc8715cfea4ced525342.camel@echosa.net> <5B2A056F.1040003@gmx.at> <874lhx6azn.fsf@gmail.com> <5B2A40B2.4020600@gmx.at> <87vaad4ji3.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=-hjCCtlrnq3IHtlM+Av56" X-Trace: blaine.gmane.org 1529525655 517 195.159.176.226 (20 Jun 2018 20:14:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 20 Jun 2018 20:14:15 +0000 (UTC) Cc: 31880@debbugs.gnu.org To: Robert Pluim , martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jun 20 22:14:10 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 1fVjUW-0008RV-PI for geb-bug-gnu-emacs@m.gmane.org; Wed, 20 Jun 2018 22:14:09 +0200 Original-Received: from localhost ([::1]:51610 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fVjWd-0005Rt-Vi for geb-bug-gnu-emacs@m.gmane.org; Wed, 20 Jun 2018 16:16:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59212) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fVjWR-0005RG-5n for bug-gnu-emacs@gnu.org; Wed, 20 Jun 2018 16:16:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fVjWM-0006Mx-SB for bug-gnu-emacs@gnu.org; Wed, 20 Jun 2018 16:16:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50093) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fVjWM-0006Lt-B9 for bug-gnu-emacs@gnu.org; Wed, 20 Jun 2018 16:16:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fVjWL-0000r2-T5 for bug-gnu-emacs@gnu.org; Wed, 20 Jun 2018 16:16:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Brian Zwahr Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 20 Jun 2018 20:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31880 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 31880-submit@debbugs.gnu.org id=B31880.15295257073218 (code B ref 31880); Wed, 20 Jun 2018 20:16:01 +0000 Original-Received: (at 31880) by debbugs.gnu.org; 20 Jun 2018 20:15:07 +0000 Original-Received: from localhost ([127.0.0.1]:57990 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fVjVS-0000pq-Mx for submit@debbugs.gnu.org; Wed, 20 Jun 2018 16:15:07 -0400 Original-Received: from out2-smtp.messagingengine.com ([66.111.4.26]:59809) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fVjVR-0000pj-H7 for 31880@debbugs.gnu.org; Wed, 20 Jun 2018 16:15:06 -0400 Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 297B021B4F; Wed, 20 Jun 2018 16:15:05 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 20 Jun 2018 16:15:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=echosa.net; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=DusdWnsuLiVIbYjnJgE98ckZJdcUDiDfQ1ugedsjsIg=; b=FptWJtn1 PCXGdajb2w19gV3VW8fgStN0z5A8QfdNTqByO+pE2ndbzoT++nX+12n6Umbxfpe/ Z9987+Q9w54E3YYITQoOsSmDQJ9RXi8DTBsQNQws3P53sffhLxed1PF79oGTbLcW gfSJ1/9GRgM+pix1gADYqPoBHnWKZEyU8wL0mfB6smtSzFAw2dkLtwZbEn5l/rnc gnhzEAmaTRRoOhDKrMjLPyM3Hb9p7qIaGTTleyFbg3cI0Iqaf8KBONkDItx5v/+G HlzXveGrOWTuPS9sVS3yqX634B6PxxENcWrNXPx7QUQPCs2lhxt3ivfNgSxK2CjV Z8/rX6BFuGNvSA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=DusdWnsuLiVIbYjnJgE98ckZJdcUD iDfQ1ugedsjsIg=; b=XFhUg8cRD7uFNGsxin/EVTKRmC5rJqcMytjUwQLlDkd59 IYr8W8wzZbXq70c0FxiCUAGL08+xpawv8KAy3qTvxk9A57Bj8+2bRvgVB789BiEB OKI2rR16mGK6Z68oDl05PsUlYYdQ5wPFSQvgwj2MeruEJfM6y9KhbPGJxFrkQa9V jObzgOJO+MuNfMPuz1p6GKNtMNLVJ7EYllhgNPYZtXGHjvv7HGwFB0C9mgio21If RTvmYKQlXyBFSF/rXlBnpjjGvsxBhTPEro3pCqi2mcHkmsTh2XKR5ZvEt8Bx8snO weY4TrRICEb0v0Ah0jlF+clDlMDpM6UOkqavB1Y2A== X-ME-Proxy: X-ME-Sender: Original-Received: from pop-os (50-24-105-222.bcstcmtk02.res.dyn.suddenlink.net [50.24.105.222]) by mail.messagingengine.com (Postfix) with ESMTPA id 7D25F1025C; Wed, 20 Jun 2018 16:15:04 -0400 (EDT) In-Reply-To: <87vaad4ji3.fsf@gmail.com> X-Mailer: Evolution 3.28.1-2 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:147670 Archived-At: --=-hjCCtlrnq3IHtlM+Av56 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit I'm not exactly sure what to do with this. I assume I need to get the latest source and build it, after applying this diff? Where do I get the source? I've never built Emacs from source before. I'll try to get to it when I can. On Wed, 2018-06-20 at 16:31 +0200, Robert Pluim wrote: > martin rudalics writes: > It should, but it doesnʼt. I see similar problems here, but I > donʼtunderstand why (unless this is another instance of "Mixing X and > GTKcalls will bite your arse eventually"). > What happens when you move a frame to the bottom of your screen > andopen a menu bar entry? Does it also get hidden? > No, menu bar menus are fine. > GTK tooltips seem to appear in the right place, so Iʼll look > forinspiration there. > It's up to GTK to decide whether a menu fits on the screen so maybe > itmesses up the height of menu bar text when scaling is in > effect. Doesscaling affect the height of menus in the first > place? Does it affectthe height of tooltips? > > Yes and yes, because it affects the size of the font used to > displaythem. > Thanks for looking into this, martin > Yet another instance of a disagreement between how GTK and X > calculatepixels. Who will rid me of this turbulent mix? > Brian, would it be possible for you to try out the following patch? > Itfixes things for me here. > diff --git i/src/xmenu.c w/src/xmenu.cindex e7ef31ac56..3a245771e1 > 100644--- i/src/xmenu.c+++ w/src/xmenu.c@@ -1162,11 +1162,16 @@ > menu_position_func (GtkMenu *menu, gint *x, gint *y, gboolean > *push_in, gpointer GtkRequisition req; int max_x = -1; int > max_y = -1;+ int scale = 1; Lisp_Object frame, > workarea; XSETFRAME (frame, data->f); +#ifdef HAVE_GTK3+ scale = > xg_get_scale (data->f);+#endif+ /* TODO: Get the monitor workarea > directly without calculating other items in x-display-monitor- > attributes-list. */ workarea = call3 (Qframe_monitor_workarea,@@ > -1192,11 +1197,18 @@ menu_position_func (GtkMenu *menu, gint *x, gint > *y, gboolean *push_in, gpointer max_y = x_display_pixel_height > (dpyinfo); } + /* frame-monitor-workarea and > {x,y}_display_pixel_width/height all+ return device pixels, but > GTK wants scaled pixels. The positions+ passed in via data were > already scaled for us. */+ max_x /= scale;+ max_y /= scale; *x = > data->x; *y = data->y; /* Check if there is room for the > menu. If not, adjust x/y so that- the menu is fully > visible. */+ the menu is fully > visible. gtk_widget_get_preferred_size returns+ scaled pixels, > so there is no need to apply the > scaling+ factor. */ gtk_widget_get_preferred_size (GTK_WIDGET > (menu), NULL, &req); if (data->x + req.width > max_x) *x -= > data->x + req.width - max_x; > > > --=-hjCCtlrnq3IHtlM+Av56 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
I'm not exactly sure what to do with this. I = assume I need to get the latest source and build it, after applying this di= ff? Where do I get the source? I've never built Emacs from source before. I= 'll try to get to it when I can.

On Wed, 2018-06-2= 0 at 16:31 +0200, Robert Pluim wrote:
martin rudalics <rudalics@gmx.at= > writes:

It should,=
 but it doesn=CA=BCt. I see similar problems here, but I don=CA=BCt
understand why (unless this is another instance of "Mixing X and GTK
calls will bite your arse eventually").

What happens when you move a frame to the bottom of your screen and=

open a menu bar entry?  Does it also get hidden?

No, menu bar menus are fine.

=

GTK tooltips seem to appear in the right place, =
so I=CA=BCll look for
inspiration there.
It's up to GTK to decide whether a menu fits on the screen so m=
aybe it
messes up the height of menu bar text when scaling is in =
effect.  Does
scaling affect the height of menus in the first pla=
ce?  Does it affect
the height of tooltips?

<=
pre>

Yes and yes, because it affects the size of t=
he font used to display
them.

Thanks for looking into this, mart=
in

Yet another instance of a disagreeme=
nt between how GTK and X calculate
pixels. Who will rid me of thi=
s turbulent mix?

Brian, would it be possible for y=
ou to try out the following patch? It
fixes things for me here.

diff --git i/src/xmenu.c w/src/xmenu.c
in=
dex e7ef31ac56..3a245771e1 100644
--- i/src/xmenu.c
+++=
 w/src/xmenu.c
@@ -1162,11 +1162,16 @@ menu_position_func (GtkMen=
u *menu, gint *x, gint *y, gboolean *push_in, gpointer
   GtkRequ=
isition req;
   int max_x =3D -1;
   int max_y =3D -1;<=
/pre>
+  int scale =3D 1;
 
   Lisp_Object frame, w=
orkarea;
 
   XSETFRAME (frame, data->f);
=
 
+#ifdef HAVE_GTK3
+  scale =3D xg_get_scale (data->=
;f);
+#endif
+
   /* TODO: Get the monitor wo=
rkarea directly without calculating other
      items in x-displa=
y-monitor-attributes-list. */
   workarea =3D call3 (Qframe_monit=
or_workarea,
@@ -1192,11 +1197,18 @@ menu_position_func (GtkMenu =
*menu, gint *x, gint *y, gboolean *push_in, gpointer
       max_y=
 =3D x_display_pixel_height (dpyinfo);
     }
 
+  /* frame-monitor-workarea and {x,y}_display_pixel_width/height all
+     return device pixels, but GTK wants scaled pixels.  The posit=
ions
+     passed in via data were already scaled for us.  */
+  max_x /=3D scale;
+  max_y /=3D scale;
   *x =
=3D data->x;
   *y =3D data->y;
 
   /*=
 Check if there is room for the menu.  If not, adjust x/y so that
-     the menu is fully visible.  */
+     the menu is fully vis=
ible.  gtk_widget_get_preferred_size returns
+     scaled pixels,=
 so there is no need to apply the scaling
+     factor.  */
=

   gtk_widget_get_preferred_size (GTK_WIDGET (menu), NULL, &req);<=
/pre>
   if (data->x + req.width > max_x)
     *x -=3D =
data->x + req.width - max_x;



--=-hjCCtlrnq3IHtlM+Av56--