unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Alex <agrambot@gmail.com>
To: 23568@debbugs.gnu.org
Subject: bug#23568: 25.0.94; Mode line menus appear incorrectly in some monitor configurations
Date: Wed, 31 May 2017 01:14:20 -0600	[thread overview]
Message-ID: <87vaoh1os3.fsf@gmail.com> (raw)
In-Reply-To: <87y3thjw4i.fsf@gmail.com> (Alex's message of "Sun, 28 May 2017 01:09:17 -0600")

Alex <agrambot@gmail.com> writes:

> This is still an issue in current master.
>
> The tooltip issue I mentioned above last year was fixed in 7b14da444, so
> I tried using pretty much the same code to fix this issue; a proof of
> concept diff is included below.
>
> I don't know if it's a good approach though. Partially because I have no
> idea why the values of req.{height, width} are so large, why they differ
> in different Emacs sessions, and how they relate to the other
> width/height variables.
>
> In any case, perhaps this functionality should be abstracted into a
> procedure that just computes the dimensions of the current monitor?
>
> diff --git a/src/xmenu.c b/src/xmenu.c
> index 2805249164..9a87fce380 100644
> --- a/src/xmenu.c
> +++ b/src/xmenu.c
> @@ -1161,8 +1161,43 @@ menu_position_func (GtkMenu *menu, gint *x, gint *y, gboolean *push_in, gpointer
>    struct next_popup_x_y *data = user_data;
>    GtkRequisition req;
>    struct x_display_info *dpyinfo = FRAME_DISPLAY_INFO (data->f);
> -  int disp_width = x_display_pixel_width (dpyinfo);
> -  int disp_height = x_display_pixel_height (dpyinfo);
> +  int disp_width;
> +  int disp_height;
> +
> +  int min_x, min_y, max_x, max_y = -1;
> +  Lisp_Object frame, attributes, monitor, geometry;
> +
> +  XSETFRAME(frame, data->f);
> +  attributes = Fx_display_monitor_attributes_list (frame);
> +
> +  /* Try to determine the current monitor's resolution */
> +  while (CONSP (attributes))
> +    {
> +      monitor = XCAR (attributes);
> +      geometry = Fassq (Qgeometry, monitor);
> +      if (CONSP (geometry))
> +        {
> +          min_x = XINT (Fnth (make_number (1), geometry));
> +          min_y = XINT (Fnth (make_number (2), geometry));
> +          max_x = min_x + XINT (Fnth (make_number (3), geometry));
> +          max_y = min_y + XINT (Fnth (make_number (4), geometry));
> +          if (min_x <= data->x && data->x < max_x
> +              && min_y <= data->y && data->y < max_y)
> +            {
> +              disp_width = max_x;
> +              disp_height = max_y;
> +              break;
> +            }
> +          max_y = -1;
> +        }
> +
> +      attributes = XCDR (attributes);
> +    }
> +  if ( max_y < 0 )
> +    {
> +      disp_width = x_display_pixel_width (dpyinfo);
> +      disp_height = x_display_pixel_height (dpyinfo);
> +    }
>  
>    *x = data->x;
>    *y = data->y;

Sorry, I copied the wrong commit hash. I meant to write that it was
fixed in c77ffc8019, which fixed bug#22549.

Martin, since you were involved with bug#22549, what do you think? Does
this seem reasonable, and should this functionality (window dimensions
of the current position's monitor) be extracted into its own procedure?





  reply	other threads:[~2017-05-31  7:14 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-17 20:44 bug#23568: 25.0.94; Mode line menus appear incorrectly in some monitor configurations Alex
2016-05-18 21:28 ` Alex
2017-05-28  7:09 ` Alex
2017-05-31  7:14   ` Alex [this message]
2017-05-31  9:26     ` martin rudalics
2017-05-31 21:18       ` Alex
2017-06-01  5:39         ` martin rudalics
2017-06-01 20:33           ` Alex
2017-06-01 20:51             ` Alex
2017-06-02  6:10               ` martin rudalics
2017-06-02  7:18                 ` Alex
2017-06-02  9:00                   ` martin rudalics
2017-06-03  0:54                     ` Alex
2017-06-03  6:32                       ` Eli Zaretskii
2017-06-03 19:19                         ` Alex
2017-06-04 14:28                           ` Eli Zaretskii
2017-06-05  8:03                             ` Alex
2017-06-05 15:36                               ` Eli Zaretskii
2017-06-05 19:33                                 ` martin rudalics
2017-06-10  9:30                               ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87vaoh1os3.fsf@gmail.com \
    --to=agrambot@gmail.com \
    --cc=23568@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).