bug#24084: 25.1; GTK3 mode-line drop down menu partially off-screen

bug#24084: 25.1; GTK3 mode-line drop down menu partially off-screen

[Sebastian Schueppel]

This is related to a multi monitor setup: I have 3 monitors set from left to right. The middle monitor has a vertical orientation therefore the pixels available on that one is swapped. The monitors have the following resolutions: (1680x1050)(1050x1680)(1680x1050)
If I do the following on one of the horizontal/normal oriented monitors the mode-line drop down menu disappears partially off-screen.

starting from 'emacs -Q'

maximize the frame on one of the monitors with normal orientation (1680x1050) and click in the mode-line on the line number or column number. The popup/dropdown menu will partially disappear at the bottom of the monitor. 

--
My debug/quickfix so far: 

The popup menus like this are defined in emacs/src/xmenu.c 
Since I'm using GTK3 the 'menu_position_func' function is always used to define the position of the popup menu. Which is certainly the correct thing to do, otherwise GTK3 does sometimes some funky stuff. Now in my 3 monitor set-up, the function within 'menu_position_func' called 'x_display_pixel_height' always thinks the height of my screen is 1680 and therefore thinks there is room to display the menu below. It doesn't take into account that one monitor is vertical oriented and has a height of 1680, but the other 2 monitor are set up normal with a height of 1080. 

I have used the following quickfix using GTK3 build in functions using monitors rather than the whole screen information. Adding the following to 'menu_position_func' to get the geometry of the monitor the frame is on. I understand that this might not be generic enough, but it works for me. 

<code>
#include <gdk/gdk.h>

GdkRectangle workarea;
// get the monitor the current frame is on
gint widgetMonitor = gdk_screen_get_monitor_at_point(gtk_widget_get_screen(FRAME_GTK_OUTER_WIDGET (data->f)),*x,*y);
gdk_screen_get_monitor_workarea(gtk_widget_get_screen(FRAME_GTK_OUTER_WIDGET (data->f)),widgetMonitor,&workarea);
// now instead of using disp_width and disp_height we use a combination of monitor absolut position and monitor working area.
// monitor absolute position being  workarea.x workarea.y and monitor size being workarea.height and workarea.width
</code>

I'm omitting the rest of the code here where those values are used as it should be obvious. Hope this will help to get a more generic solution out there. 



In GNU Emacs 25.1.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8)
 of 2016-07-26 built on mymachine
Repository revision: 0f0b191a5324115fe9e8c438eceef4043decf209
Windowing system distributor 'The X.Org Foundation', version 11.0.11501000
System Description:    Ubuntu 14.04.4 LTS

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND DBUS GSETTINGS NOTIFY LIBSELINUX GNUTLS
LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
  value of $LC_ALL: en_NZ.utf-8
  value of $LANG: en_NZ.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode easymenu
cl-loaddefs pcase cl-lib mail-prsvr mail-utils time-date mule-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote dbusbind inotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 90185 6392)
 (symbols 48 19738 0)
 (miscs 40 363 146)
 (strings 32 14712 4043)
 (string-bytes 1 433457)
 (vectors 16 12041)
 (vector-slots 8 437199 5168)
 (floats 8 165 69)
 (intervals 56 240 10)
 (buffers 976 22)
 (heap 1024 30448 957))

bug#24084: 25.1; GTK3 mode-line drop down menu partially off-screen

[Alex]

Sebastian Schueppel <Sebastian.Schueppel@endace.com> writes:

> This is related to a multi monitor setup: I have 3 monitors set from left to
> right. The middle monitor has a vertical orientation therefore the pixels
> available on that one is swapped. The monitors have the following resolutions:
> (1680x1050)(1050x1680)(1680x1050)
> If I do the following on one of the horizontal/normal oriented monitors the mode-line drop down menu disappears partially off-screen.
>
> starting from 'emacs -Q'
>
> maximize the frame on one of the monitors with normal orientation (1680x1050)
> and click in the mode-line on the line number or column number. The
> popup/dropdown menu will partially disappear at the bottom of the monitor.
>
> --
> My debug/quickfix so far: 
>
> The popup menus like this are defined in emacs/src/xmenu.c 
> Since I'm using GTK3 the 'menu_position_func' function is always used to define the position of the popup menu. Which is certainly the correct thing to do, otherwise GTK3 does sometimes some funky stuff. Now in my 3 monitor set-up, the function within 'menu_position_func' called 'x_display_pixel_height' always thinks the height of my screen is 1680 and therefore thinks there is room to display the menu below. It doesn't take into account that one monitor is vertical oriented and has a height of 1680, but the other 2 monitor are set up normal with a height of 1080. 
>
> I have used the following quickfix using GTK3 build in functions using monitors rather than the whole screen information. Adding the following to 'menu_position_func' to get the geometry of the monitor the frame is on. I understand that this might not be generic enough, but it works for me. 
>
> <code>
> #include <gdk/gdk.h>
>
> GdkRectangle workarea;
> // get the monitor the current frame is on
> gint widgetMonitor = gdk_screen_get_monitor_at_point(gtk_widget_get_screen(FRAME_GTK_OUTER_WIDGET (data->f)),*x,*y);
> gdk_screen_get_monitor_workarea(gtk_widget_get_screen(FRAME_GTK_OUTER_WIDGET (data->f)),widgetMonitor,&workarea);
> // now instead of using disp_width and disp_height we use a combination of monitor absolut position and monitor working area.
> // monitor absolute position being  workarea.x workarea.y and monitor size being workarea.height and workarea.width
> </code>
>
> I'm omitting the rest of the code here where those values are used as it should be obvious. Hope this will help to get a more generic solution out there. 

I believe this is fixed in the latest master. Can you confirm? It should
work for any GTK version.

bug#24084: 25.1; GTK3 mode-line drop down menu partially off-screen

[Stefan Kangas]

Alex <agrambot@gmail.com> writes:

> Sebastian Schueppel <Sebastian.Schueppel@endace.com> writes:
>
>> This is related to a multi monitor setup: I have 3 monitors set from left to
>> right. The middle monitor has a vertical orientation therefore the pixels
>> available on that one is swapped. The monitors have the following resolutions:
>> (1680x1050)(1050x1680)(1680x1050)
>> If I do the following on one of the horizontal/normal oriented monitors the mode-line drop down menu disappears partially off-screen.
>>
>> starting from 'emacs -Q'
>>
>> maximize the frame on one of the monitors with normal orientation (1680x1050)
>> and click in the mode-line on the line number or column number. The
>> popup/dropdown menu will partially disappear at the bottom of the monitor.
>>
>> --
>> My debug/quickfix so far:
>>
>> The popup menus like this are defined in emacs/src/xmenu.c
>> Since I'm using GTK3 the 'menu_position_func' function is always used to
>> define the position of the popup menu. Which is certainly the correct thing to
>> do, otherwise GTK3 does sometimes some funky stuff. Now in my 3 monitor
>> set-up, the function within 'menu_position_func' called
>> 'x_display_pixel_height' always thinks the height of my screen is 1680 and
>> therefore thinks there is room to display the menu below. It doesn't take into
>> account that one monitor is vertical oriented and has a height of 1680, but
>> the other 2 monitor are set up normal with a height of 1080.
>>
>> I have used the following quickfix using GTK3 build in functions using
>> monitors rather than the whole screen information. Adding the following to
>> 'menu_position_func' to get the geometry of the monitor the frame is on. I
>> understand that this might not be generic enough, but it works for me.
>>
>> <code>
>> #include <gdk/gdk.h>
>>
>> GdkRectangle workarea;
>> // get the monitor the current frame is on
>> gint widgetMonitor = gdk_screen_get_monitor_at_point(gtk_widget_get_screen(FRAME_GTK_OUTER_WIDGET (data->f)),*x,*y);
>> gdk_screen_get_monitor_workarea(gtk_widget_get_screen(FRAME_GTK_OUTER_WIDGET (data->f)),widgetMonitor,&workarea);
>> // now instead of using disp_width and disp_height we use a combination of monitor absolut position and monitor working area.
>> // monitor absolute position being  workarea.x workarea.y and monitor size being workarea.height and workarea.width
>> </code>
>>
>> I'm omitting the rest of the code here where those values are used as it should be obvious. Hope this will help to get a more generic solution out there.
>
> I believe this is fixed in the latest master. Can you confirm? It should
> work for any GTK version.

I can't reproduce this on current master using GTK+ Version 3.24.5.

Since a verification for a fix was requested over 2 years ago, and none
was given, I'm going to assume this is no longer an issue.  I'm
therefore closing this bug report.

If anyone can still reproduce this, please reopen.

Best regards,
Stefan Kangas