GNU bug report logs - #31880
26.1; VC mode line popup when clicked is off screen

Previous Next

Full log

Message #23 received at 31880 <at> debbugs.gnu.org (full text, mbox):

From: Brian Zwahr <echosa <at> echosa.net>
To: Robert Pluim <rpluim <at> gmail.com>, martin rudalics <rudalics <at> gmx.at>
Cc: 31880 <at> debbugs.gnu.org
Subject: Re: bug#31880: 26.1; VC mode line popup when clicked is off screen
Date: Wed, 20 Jun 2018 15:15:03 -0500

[Message part 1 (text/plain, inline)]

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 <rudalics <at> gmx.at> 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;
> 
> 
> 

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.