bug#31223: 25.3; New menus are empty with GTK3

bug#31223: 25.3; New menus are empty with GTK3

[Thomas Schneider]

When changing to a mode that provides new menus (e. g. AUCTeX), new
menus appear in the menu bar (LaTeX and Command in this case), but they
appear empty.  This is only the case with GTK3; GTK2, Motif and terminal
do not show this behaviour.

In fact, it looks very much like bug#4122, just for GTK3 instead of
GTK2.  Launching Emacs with GDK_NATIVE_WINDOWS=1 as suggested in
lp#415101 does not help.



In GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.29)
 of 2018-04-20 built on coruscant
Windowing system distributor 'The X.Org Foundation', version 11.0.11905000
System Description:	Gentoo Base System release 2.4.1

Configured using:
 'configure --prefix=/usr --build=x86_64-pc-linux-gnu
 --host=x86_64-pc-linux-gnu --mandir=/usr/share/man
 --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
 --localstatedir=/var/lib --disable-dependency-tracking
 --disable-silent-rules --docdir=/usr/share/doc/emacs-25.3-r4
 --htmldir=/usr/share/doc/emacs-25.3-r4/html --libdir=/usr/lib64
 --program-suffix=-emacs-25 --infodir=/usr/share/info/emacs-25
 --localstatedir=/var
 --enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp
 --with-gameuser=:gamestat --without-compress-install --without-hesiod
 --with-file-notification=inotify --enable-acl --with-dbus
 --without-modules --with-gpm --with-kerberos --with-kerberos5
 --with-xml2 --without-selinux --with-gnutls --without-wide-int
 --with-zlib --with-sound=alsa --with-x --without-ns --without-gconf
 --with-gsettings --with-toolkit-scroll-bars --with-gif --with-jpeg
 --with-png --with-rsvg --with-tiff --with-xpm --without-imagemagick
 --with-xft --without-cairo --without-libotf --without-m17n-flt
 --with-x-toolkit=gtk3 --without-xwidgets 'CFLAGS=-O2 -pipe
 -march=native' CPPFLAGS= 'LDFLAGS=-Wl,-O1 -Wl,--as-needed''

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

Important settings:
  value of $LANG: en_DK.UTF-8
  locale-coding-system: utf-8-unix

Major mode: notmuch-hello

Minor modes in effect:
  diff-auto-refine-mode: t
  shell-dirtrack-mode: t
  TeX-PDF-mode: t
  linum-relative-global-mode: t
  linum-relative-mode: t
  linum-mode: t
  override-global-mode: t
  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
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Loading /home/qsx/RWTH/ProSem/auto/main.el (source)...done
Loading /usr/share/emacs/etc/auctex/style/cleveref.elc...done
Loading /usr/share/emacs/etc/auctex/style/graphicx.elc...done
Loading /usr/share/emacs/etc/auctex/style/hyperref.elc...done
Loading /usr/share/emacs/etc/auctex/style/url.elc...done
Loading /usr/share/emacs/etc/auctex/style/nameref.elc...done
Loading /home/qsx/RWTH/ProSem/auto/references.el (source)...done
Applying style hooks...done
Mark set
Making completion list...

Load-path shadows:
None found.

Features:
(notmuch hl-line notmuch-message notmuch-hello wid-edit notmuch-tree
notmuch-show notmuch-print notmuch-crypto notmuch-mua notmuch-draft
notmuch-maildir-fcc notmuch-address notmuch-company notmuch-parser
notmuch-wash coolj notmuch-query goto-addr thingatpt icalendar diary-lib
diary-loaddefs cal-menu calendar cal-loaddefs notmuch-tag notmuch-lib
notmuch-version notmuch-compat mm-view mml-smime smime dig mailcap
vc-git diff-mode tex-bar tex-buf toolbar-x noutline outline font-latex
latex tex-ispell tex-style tex-mode compile shell pcomplete comint
ansi-color ring latexenc pp shadow sort mail-extr warnings emacsbug
sendmail gnus-alias message idna dired format-spec rfc822 mml mml-sec
password-cache epg gnus-util mm-decode mm-bodies mm-encode mail-parse
rfc2231 rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr
mailabbrev mail-utils gmm-utils mailheader edmacro kmacro tex dbus xml
crm linum-relative advice linum sanityinc-tomorrow-blue-theme
color-theme-sanityinc-tomorrow color server use-package cl bind-key
cl-macs easy-mmode finder-inf package epg-config seq byte-opt gv
bytecomp byte-compile cl-extra help-mode easymenu cconv cl-loaddefs
pcase cl-lib site-gentoo auto-loads tex-site 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 220924 12586)
 (symbols 48 30924 1)
 (miscs 40 410 390)
 (strings 32 48671 8307)
 (string-bytes 1 1396879)
 (vectors 16 22835)
 (vector-slots 8 564521 12167)
 (floats 8 412 147)
 (intervals 56 771 114)
 (buffers 976 24))

bug#31223: 25.3; New menus are empty with GTK3

[Thomas Schneider]

The same problem still happens with Emacs 26.1.  I switched to using
Motiv in the meantime, but I would appreciate it if this issue could be
fixed.

bug#31223: 25.3; New menus are empty with GTK3

[Eli Zaretskii]

> From: Thomas Schneider <qsx@chaotikum.eu>
> Date: Tue, 01 May 2018 18:16:42 +0200
> 
> The same problem still happens with Emacs 26.1.

Can you send a screenshot showing the empty menus?

Thanks.

bug#31223: 25.3; New menus are empty with GTK3

[Thomas Schneider]

[-- Attachment #1: Type: text/plain, Size: 442 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thomas Schneider <qsx@chaotikum.eu>
>> Date: Tue, 01 May 2018 18:16:42 +0200
>> 
>> The same problem still happens with Emacs 26.1.
>
> Can you send a screenshot showing the empty menus?
Sure.  This is with emacs -Q, so instead of AUCTeX as described in the
initial report, this is Emacs’ TeX mode (I don’t know what it is really
called), but the problem is the same nonetheless.

[-- Attachment #2: Screenshot --]
[-- Type: image/png, Size: 58032 bytes --]

bug#31223: 25.3; New menus are empty with GTK3

[Eli Zaretskii]

> From: Thomas Schneider <qsx@chaotikum.eu>
> Cc: 31223@debbugs.gnu.org
> Date: Tue, 01 May 2018 19:01:59 +0200
> 
> Sure.  This is with emacs -Q, so instead of AUCTeX as described in the
> initial report, this is Emacs’ TeX mode (I don’t know what it is really
> called), but the problem is the same nonetheless.

So you are saying that when you click on "Text" in this case, no menu
drops down, is that right?

Do these menus ever get "filled", or do they stay empty no matter what
you do?

bug#31223: 25.3; New menus are empty with GTK3

[Thomas Schneider]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thomas Schneider <qsx@chaotikum.eu>
>> Cc: 31223@debbugs.gnu.org
>> Date: Tue, 01 May 2018 19:01:59 +0200
>> 
>> Sure.  This is with emacs -Q, so instead of AUCTeX as described in the
>> initial report, this is Emacs’ TeX mode (I don’t know what it is really
>> called), but the problem is the same nonetheless.
>
> So you are saying that when you click on "Text" in this case, no menu
> drops down, is that right?

If you watch closely, you can see that a menu spawns, but contains no
items at all.

> Do these menus ever get "filled", or do they stay empty no matter what
> you do?

If I open the menu with F10, they are filled normally, as well M-x
accelerate-menu RET.

bug#31223: 25.3; New menus are empty with GTK3

[Eli Zaretskii]

> > So you are saying that when you click on "Text" in this case, no menu
> > drops down, is that right?
> 
> If you watch closely, you can see that a menu spawns, but contains no
> items at all.
> 
> > Do these menus ever get "filled", or do they stay empty no matter what
> > you do?
> 
> If I open the menu with F10, they are filled normally, as well M-x
> accelerate-menu RET.

And if, after that, you click on the menu with the mouse, you then see
the menu drop down normally?

bug#31223: 25.3; New menus are empty with GTK3

[Noam Postavsky]

Thomas Schneider <qsx@chaotikum.eu> writes:

> When changing to a mode that provides new menus (e. g. AUCTeX), new
> menus appear in the menu bar (LaTeX and Command in this case), but they
> appear empty.  This is only the case with GTK3; GTK2, Motif and terminal
> do not show this behaviour.
>
> In fact, it looks very much like bug#4122, just for GTK3 instead of
> GTK2.  Launching Emacs with GDK_NATIVE_WINDOWS=1 as suggested in
> lp#415101 does not help.
>
>
>
> In GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.29)

For the record, I'm unable to reproduce this here (with GTK version
3.22.11).

bug#31223: 25.3; New menus are empty with GTK3

[Thomas Schneider]

Eli Zaretskii <eliz@gnu.org> writes:

>> > So you are saying that when you click on "Text" in this case, no menu
>> > drops down, is that right?
>> 
>> If you watch closely, you can see that a menu spawns, but contains no
>> items at all.
>> 
>> > Do these menus ever get "filled", or do they stay empty no matter what
>> > you do?
>> 
>> If I open the menu with F10, they are filled normally, as well M-x
>> accelerate-menu RET.
>
> And if, after that, you click on the menu with the mouse, you then see
> the menu drop down normally?

Yes.  As soon as I once opened the menu via F10 or another method, I can
use them with the mouse normally.  Until they are updated again
(e. g. switching to a buffer with a different mode and own menus), then
the content has disappeared again.

bug#31223: 25.3; New menus are empty with GTK3

[Eli Zaretskii]

> From: Thomas Schneider <qsx@chaotikum.eu>
> Cc: 31223@debbugs.gnu.org
> Date: Thu, 03 May 2018 10:36:59 +0200
> 
> >> If I open the menu with F10, they are filled normally, as well M-x
> >> accelerate-menu RET.
> >
> > And if, after that, you click on the menu with the mouse, you then see
> > the menu drop down normally?
> 
> Yes.  As soon as I once opened the menu via F10 or another method, I can
> use them with the mouse normally.  Until they are updated again
> (e. g. switching to a buffer with a different mode and own menus), then
> the content has disappeared again.

I guess someone needs to step through GTK-specific parts of xmenu.c,
where it fills up the menus, and through the relevant subroutines in
gtkutil.c, and see what fails there and why.

bug#31223: 25.3; New menus are empty with GTK3

[Noam Postavsky]

merge 23672 28106 31223
quit

Thomas Schneider <qsx@chaotikum.eu> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Thomas Schneider <qsx@chaotikum.eu>
>>> Date: Tue, 01 May 2018 18:16:42 +0200
>>> 
>>> The same problem still happens with Emacs 26.1.
>>
>> Can you send a screenshot showing the empty menus?
> Sure.  This is with emacs -Q, so instead of AUCTeX as described in the
> initial report, this is Emacs’ TeX mode (I don’t know what it is really
> called), but the problem is the same nonetheless.

It looks like this and #28106 "menu empty in menu bar" are dups of
#23672.

bug#31223: [PATCH] Fix empty/incorrect GTK menus on HiDPI monitors with window scaling factor > 1

[Tobias Bading]

[-- Attachment #1: Type: text/plain, Size: 771 bytes --]

This should fix Bug#31223, Bug#28106, Bug#23672 as well as Ubuntu bug
https://bugs.launchpad.net/ubuntu/+source/emacs25/+bug/1695228

Also fixes the formerly unscaled Y value returned by
frame-monitor-workarea (and display-monitor-attributes-list).

For details on why some GTK menus were empty please see thread
https://lists.gnu.org/archive/html/emacs-devel/2019-11/msg01061.html

* src/gtkutil.c
   (menubar_map_cb): properly scale req.height so that the menu bar's
   height is in device pixels as expected
   (xg_update_frame_menubar): dito
   (xg_event_is_for_menubar): properly scale rec.x and rec.y so that
   gtk_widget_intersect() works as intended
* src/xfns.c
   (Fx_display_monitor_attributes_list): properly scale work.x and work.y


[-- Attachment #2: 0001-Fix-empty-incorrect-GTK-menus-on-HiDPI-monitors.patch --]
[-- Type: text/x-patch, Size: 2765 bytes --]

From ee5855067f50f6e208a960994eec7184d44d324e Mon Sep 17 00:00:00 2001
From: Tobias Bading <tbading@web.de>
Date: Wed, 27 Nov 2019 16:51:26 +0100
Subject: [PATCH] Fix empty/incorrect GTK menus on HiDPI monitors with window
 scaling factor > 1

This should fix Bug#31223, Bug#28106, Bug#23672 as well as Ubuntu bug
https://bugs.launchpad.net/ubuntu/+source/emacs25/+bug/1695228

Also fixes the formerly unscaled Y value returned by
frame-monitor-workarea (and display-monitor-attributes-list).

For details on why some GTK menus were empty please see thread
https://lists.gnu.org/archive/html/emacs-devel/2019-11/msg01061.html

* src/gtkutil.c
  (menubar_map_cb): properly scale req.height so that the menu bar's
  height is in device pixels as expected
  (xg_update_frame_menubar): dito
  (xg_event_is_for_menubar): properly scale rec.x and rec.y so that
  gtk_widget_intersect() works as intended
* src/xfns.c
  (Fx_display_monitor_attributes_list): properly scale work.x and work.y
---
 src/gtkutil.c | 8 +++++---
 src/xfns.c    | 2 ++
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/gtkutil.c b/src/gtkutil.c
index cf5c31aa20..7e6db57c9d 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -3471,6 +3471,7 @@ menubar_map_cb (GtkWidget *w, gpointer user_data)
   GtkRequisition req;
   struct frame *f = user_data;
   gtk_widget_get_preferred_size (w, NULL, &req);
+  req.height *= xg_get_scale (f);
   if (FRAME_MENUBAR_HEIGHT (f) != req.height)
     {
       FRAME_MENUBAR_HEIGHT (f) = req.height;
@@ -3502,7 +3503,7 @@ xg_update_frame_menubar (struct frame *f)
   g_signal_connect (x->menubar_widget, "map", G_CALLBACK (menubar_map_cb), f);
   gtk_widget_show_all (x->menubar_widget);
   gtk_widget_get_preferred_size (x->menubar_widget, NULL, &req);
-
+  req.height *= xg_get_scale (f);
   if (FRAME_MENUBAR_HEIGHT (f) != req.height)
     {
       FRAME_MENUBAR_HEIGHT (f) = req.height;
@@ -3568,8 +3569,9 @@ xg_event_is_for_menubar (struct frame *f, const XEvent *event)

   list = gtk_container_get_children (GTK_CONTAINER (x->menubar_widget));
   if (! list) return 0;
-  rec.x = event->xbutton.x;
-  rec.y = event->xbutton.y;
+  int scale = xg_get_scale (f);
+  rec.x = event->xbutton.x / scale;
+  rec.y = event->xbutton.y / scale;
   rec.width = 1;
   rec.height = 1;

diff --git a/src/xfns.c b/src/xfns.c
index b1b40702c2..47aa19607f 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -5093,6 +5093,8 @@ DEFUN ("x-display-monitor-attributes-list", Fx_display_monitor_attributes_list,
 #endif
       rec.width *= scale;
       rec.height *= scale;
+      work.x *= scale;
+      work.y *= scale;
       work.width *= scale;
       work.height *= scale;

--
2.20.1

bug#31223: [PATCH] Fix empty/incorrect GTK menus on HiDPI monitors with window scaling factor > 1

[Robert Pluim]

>>>>> On Wed, 27 Nov 2019 17:03:32 +0100, Tobias Bading <tbading@web.de> said:

    Tobias> This should fix Bug#31223, Bug#28106, Bug#23672 as well as Ubuntu bug
    Tobias> https://bugs.launchpad.net/ubuntu/+source/emacs25/+bug/1695228

If those are all the same bug we should merge them.

    Tobias> Also fixes the formerly unscaled Y value returned by
    Tobias> frame-monitor-workarea (and display-monitor-attributes-list).

    Tobias> For details on why some GTK menus were empty please see thread
    Tobias> https://lists.gnu.org/archive/html/emacs-devel/2019-11/msg01061.html

Thanks for that, I can reproduce with that (I never use the Dired
menus).

    Tobias> diff --git a/src/gtkutil.c b/src/gtkutil.c
    Tobias> index cf5c31aa20..7e6db57c9d 100644
    Tobias> --- a/src/gtkutil.c
    Tobias> +++ b/src/gtkutil.c
    Tobias> @@ -3471,6 +3471,7 @@ menubar_map_cb (GtkWidget *w, gpointer user_data)
    Tobias>    GtkRequisition req;
    Tobias>    struct frame *f = user_data;
    Tobias>    gtk_widget_get_preferred_size (w, NULL, &req);
    Tobias> +  req.height *= xg_get_scale (f);
    Tobias>    if (FRAME_MENUBAR_HEIGHT (f) != req.height)
    Tobias>      {
    Tobias>        FRAME_MENUBAR_HEIGHT (f) = req.height;
    Tobias> @@ -3502,7 +3503,7 @@ xg_update_frame_menubar (struct frame *f)
    Tobias>    g_signal_connect (x->menubar_widget, "map", G_CALLBACK (menubar_map_cb), f);
    Tobias>    gtk_widget_show_all (x->menubar_widget);
    Tobias>    gtk_widget_get_preferred_size (x->menubar_widget, NULL, &req);
    Tobias> -
    Tobias> +  req.height *= xg_get_scale (f);
    Tobias>    if (FRAME_MENUBAR_HEIGHT (f) != req.height)
    Tobias>      {
    Tobias>        FRAME_MENUBAR_HEIGHT (f) = req.height;

Yes.

    Tobias> @@ -3568,8 +3569,9 @@ xg_event_is_for_menubar (struct frame *f, const XEvent *event)

    Tobias>    list = gtk_container_get_children (GTK_CONTAINER (x->menubar_widget));
    Tobias>    if (! list) return 0;
    Tobias> -  rec.x = event->xbutton.x;
    Tobias> -  rec.y = event->xbutton.y;
    Tobias> +  int scale = xg_get_scale (f);
    Tobias> +  rec.x = event->xbutton.x / scale;
    Tobias> +  rec.y = event->xbutton.y / scale;
    Tobias>    rec.width = 1;
    Tobias>    rec.height = 1;

Yes. You need this as well, I think:

diff --git a/src/gtkutil.c b/src/gtkutil.c
index cf5c31aa20..4f8b06941b 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -3503,6 +3503,8 @@ xg_update_frame_menubar (struct frame *f)
   gtk_widget_show_all (x->menubar_widget);
   gtk_widget_get_preferred_size (x->menubar_widget, NULL, &req);
 
+  req.height *= xg_get_scale (f);
   if (FRAME_MENUBAR_HEIGHT (f) != req.height)
     {
       FRAME_MENUBAR_HEIGHT (f) = req.height;

    Tobias> diff --git a/src/xfns.c b/src/xfns.c
    Tobias> index b1b40702c2..47aa19607f 100644
    Tobias> --- a/src/xfns.c
    Tobias> +++ b/src/xfns.c
    Tobias> @@ -5093,6 +5093,8 @@ DEFUN ("x-display-monitor-attributes-list", Fx_display_monitor_attributes_list,
    Tobias>  #endif
    Tobias>        rec.width *= scale;
    Tobias>        rec.height *= scale;
    Tobias> +      work.x *= scale;
    Tobias> +      work.y *= scale;
    Tobias>        work.width *= scale;
    Tobias>        work.height *= scale;

This seems correct as well. Probably rec.x and rec.y need scaling as well, for
the multi-monitor case, which will require some cabling for me to test.

Robert

bug#31223: [PATCH] Fix empty/incorrect GTK menus on HiDPI monitors with window scaling factor > 1

[Tobias Bading]

On 28.11.19 09:20, Robert Pluim wrote:
 >>>>>> On Wed, 27 Nov 2019 17:03:32 +0100, Tobias Bading
<tbading@web.de> said:
 >
 >     Tobias> This should fix Bug#31223, Bug#28106, Bug#23672 as well
as Ubuntu bug
 >     Tobias>
https://bugs.launchpad.net/ubuntu/+source/emacs25/+bug/1695228
 >
 > If those are all the same bug we should merge them.

Noam Postavsky already did that over a year ago, although I have no idea
what
"merging" means in this bug tracker. The new comments don't appear in the
merged reports and there's no indication as to which report became kind
of the
leading one after the merged. I simply chose 31223 because that's the
one Noam
sent his "merge 23672 28106 31223" command to, if I'm reading it right.

 > Yes. You need this as well, I think:
 >
 > diff --git a/src/gtkutil.c b/src/gtkutil.c
 > index cf5c31aa20..4f8b06941b 100644
 > --- a/src/gtkutil.c
 > +++ b/src/gtkutil.c
 > @@ -3503,6 +3503,8 @@ xg_update_frame_menubar (struct frame *f)
 >    gtk_widget_show_all (x->menubar_widget);
 >    gtk_widget_get_preferred_size (x->menubar_widget, NULL, &req);
 >
 > +  req.height *= xg_get_scale (f);
 >    if (FRAME_MENUBAR_HEIGHT (f) != req.height)
 >      {
 >        FRAME_MENUBAR_HEIGHT (f) = req.height;

This change in xg_update_frame_menubar is already a part of my patch,
with the
only difference that I replaced the empty line. Or am I reading this hunk
wrong?

 >     Tobias> diff --git a/src/xfns.c b/src/xfns.c
 >     Tobias> index b1b40702c2..47aa19607f 100644
 >     Tobias> --- a/src/xfns.c
 >     Tobias> +++ b/src/xfns.c
 >     Tobias> @@ -5093,6 +5093,8 @@ DEFUN
("x-display-monitor-attributes-list", Fx_display_monitor_attributes_list,
 >     Tobias>  #endif
 >     Tobias>        rec.width *= scale;
 >     Tobias>        rec.height *= scale;
 >     Tobias> +      work.x *= scale;
 >     Tobias> +      work.y *= scale;
 >     Tobias>        work.width *= scale;
 >     Tobias>        work.height *= scale;
 >
 > This seems correct as well. Probably rec.x and rec.y need scaling as
well, for
 > the multi-monitor case, which will require some cabling for me to test.

Good point. The documentation of gdk_monitor_get_geometry() says

"Retrieves the size and position of an individual monitor within the display
coordinate space. The returned geometry is in "application pixels", not in
"device pixels" (see gdk_monitor_get_scale_factor())."

Unfortunately, I don't have a second monitor at hand to test this.

Tobias

bug#31223: [PATCH] Fix empty/incorrect GTK menus on HiDPI monitors with window scaling factor > 1

[Robert Pluim]

>>>>> On Thu, 28 Nov 2019 10:32:39 +0100, Tobias Bading <tbading@web.de> said:
    >> If those are all the same bug we should merge them.

    Tobias> Noam Postavsky already did that over a year ago, although I have no idea
    Tobias> what
    Tobias> "merging" means in this bug tracker. The new comments don't appear in the
    Tobias> merged reports and there's no indication as to which report became kind
    Tobias> of the
    Tobias> leading one after the merged. I simply chose 31223 because that's the
    Tobias> one Noam
    Tobias> sent his "merge 23672 28106 31223" command to, if I'm reading it right.

Iʼm seeing your messages and mine in 31223. I donʼt think it matters
which one you choose.

    Tobias> This change in xg_update_frame_menubar is already a part of my patch,
    Tobias> with the
    Tobias> only difference that I replaced the empty line. Or am I reading this hunk
    Tobias> wrong?

Yes, my mistake, I oversnipped the diff.

    >> This seems correct as well. Probably rec.x and rec.y need scaling as
    Tobias> well, for
    >> the multi-monitor case, which will require some cabling for me to test.

    Tobias> Good point. The documentation of gdk_monitor_get_geometry() says

    Tobias> "Retrieves the size and position of an individual monitor within the display
    Tobias> coordinate space. The returned geometry is in "application pixels", not in
    Tobias> "device pixels" (see gdk_monitor_get_scale_factor())."

    Tobias> Unfortunately, I don't have a second monitor at hand to test this.

I do, but not until tonight at the earliest.

Regards

Robert

bug#31223: [PATCH] Fix empty/incorrect GTK menus on HiDPI monitors with window scaling factor > 1

[Noam Postavsky]

Tobias Bading <tbading@web.de> writes:

> although I have no idea what "merging" means in this bug tracker.

Practically, it just means that closing (or tagging, etc) one will close
them all.  Also, merged bugs are crosslinked at the top their web page
(e.g., https://debbugs.gnu.org/31223).

bug#31223: [PATCH] Fix empty/incorrect GTK menus on HiDPI monitors with window scaling factor > 1

[Robert Pluim]

>>>>> On Thu, 28 Nov 2019 10:44:08 +0100, Robert Pluim <rpluim@gmail.com> said:
    >>> This seems correct as well. Probably rec.x and rec.y need scaling as
    Tobias> well, for
    >>> the multi-monitor case, which will require some cabling for me to test.

    Tobias> Good point. The documentation of gdk_monitor_get_geometry() says

    Tobias> "Retrieves the size and position of an individual monitor within the display
    Tobias> coordinate space. The returned geometry is in "application pixels", not in
    Tobias> "device pixels" (see gdk_monitor_get_scale_factor())."

    Tobias> Unfortunately, I don't have a second monitor at hand to test this.

So initial testing seems to show that the x/y positions of the second
monitor need scaling as well, but I didnʼt get around to testing all
the scaling/relative positioning combinations. Since thatʼs a less
common use case, we can apply your patch in the meantime. Do you have
an Emacs copyright assignment on file? If not, Eli, is the patch small
enough to apply without an assignment?

Thanks

Robert

bug#31223: [PATCH] Fix empty/incorrect GTK menus on HiDPI monitors with window scaling factor > 1

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Mon, 02 Dec 2019 11:35:03 +0100
> Cc: 31223@debbugs.gnu.org
> 
> Do you have an Emacs copyright assignment on file?

No, not AFAICT.

> If not, Eli, is the patch small enough to apply without an
> assignment?

Yes.

bug#31223: [PATCH] Fix empty/incorrect GTK menus on HiDPI monitors with window scaling factor > 1

[Robert Pluim]

>>>>> On Mon, 02 Dec 2019 17:53:16 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Date: Mon, 02 Dec 2019 11:35:03 +0100
    >> Cc: 31223@debbugs.gnu.org
    >> 
    >> Do you have an Emacs copyright assignment on file?

    Eli> No, not AFAICT.

    >> If not, Eli, is the patch small enough to apply without an
    >> assignment?

    Eli> Yes.

OK, pushed as a05bafffdc , with some minor changes to the commit
message.

Iʼll leave the bug open until I get a chance to verify the
multi-monitor cases.

Robert

bug#31223: [PATCH] Fix empty/incorrect GTK menus on HiDPI monitors with window scaling factor > 1

[Robert Pluim]

>>>>> On Tue, 03 Dec 2019 09:22:16 +0100, Robert Pluim <rpluim@gmail.com> said:

    Robert> Iʼll leave the bug open until I get a chance to verify the
    Robert> multi-monitor cases.

So the multi-monitor case is either interesting or annoying, depending
on your point of view.

Under Wayland GTK supports per-monitor scaling values, and returns
scaled values for the geometry of the monitors, so normally you'd need
to scale width/height and the coordinates of the top left corner for
each monitor. However, let's say you have two monitors next to each
other, with the tops aligned:

A: 3840x2160 | B: 1920x1080

with scaling factors A: 2, B: 1

You'd want to report the geometry of B as

(3840 0 1920 1080)

but because the GTK API gives you scaled values, it becomes

(1920 0 1920 1080)

which is incoherent with the workarea, where we are scaling back up:

(3840 0 1920 1080)

Normally you wouldnʼt know that you need to scale this by 2, except
that the scaling factor of B is actually reported as 2, not 1, so
applying scaling gets us the right answer. This 'error' in reporting
the scaling factor is because Emacs is not a pure GTK application: a
pure GTK application reports 2 and 1 for the scaling factors.

So until Emacs is a pure GTK app [1], I propose the following:

diff --git a/src/xfns.c b/src/xfns.c
index 47aa19607f..51a46bd6db 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -5091,6 +5091,8 @@ DEFUN ("x-display-monitor-attributes-list", Fx_display_monitor_attributes_list,
 #elif defined HAVE_GTK3
       scale = gdk_screen_get_monitor_scale_factor (gscreen, i);
 #endif
+      rec.x *= scale;
+      rec.y *= scale;
       rec.width *= scale;
       rec.height *= scale;
       work.x *= scale;

Footnotes:
[1]  When it is, we can stop doing this scaling entirely, the toolkit
     will take care of it for us.

bug#31223: [PATCH] Fix empty/incorrect GTK menus on HiDPI monitors with window scaling factor > 1

[Robert Pluim]

>>>>> On Tue, 17 Dec 2019 15:43:50 +0100, Robert Pluim <rpluim@gmail.com> said:
    Robert> diff --git a/src/xfns.c b/src/xfns.c
    Robert> index 47aa19607f..51a46bd6db 100644
    Robert> --- a/src/xfns.c
    Robert> +++ b/src/xfns.c
    Robert> @@ -5091,6 +5091,8 @@ DEFUN ("x-display-monitor-attributes-list", Fx_display_monitor_attributes_list,
    Robert>  #elif defined HAVE_GTK3
    Robert>        scale = gdk_screen_get_monitor_scale_factor (gscreen, i);
    Robert>  #endif
    Robert> +      rec.x *= scale;
    Robert> +      rec.y *= scale;
    Robert>        rec.width *= scale;
    Robert>        rec.height *= scale;
    Robert>        work.x *= scale;

Eli, is this OK for emacs-27? It will only affect
display-monitor-attributes-list for people using GTK on multiple
monitors where one is HiDPI.

Robert

bug#31223: [PATCH] Fix empty/incorrect GTK menus on HiDPI monitors with window scaling factor > 1

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 31223@debbugs.gnu.org,  tbading@web.de
> Date: Tue, 07 Jan 2020 17:15:04 +0100
> 
> >>>>> On Tue, 17 Dec 2019 15:43:50 +0100, Robert Pluim <rpluim@gmail.com> said:
>     Robert> diff --git a/src/xfns.c b/src/xfns.c
>     Robert> index 47aa19607f..51a46bd6db 100644
>     Robert> --- a/src/xfns.c
>     Robert> +++ b/src/xfns.c
>     Robert> @@ -5091,6 +5091,8 @@ DEFUN ("x-display-monitor-attributes-list", Fx_display_monitor_attributes_list,
>     Robert>  #elif defined HAVE_GTK3
>     Robert>        scale = gdk_screen_get_monitor_scale_factor (gscreen, i);
>     Robert>  #endif
>     Robert> +      rec.x *= scale;
>     Robert> +      rec.y *= scale;
>     Robert>        rec.width *= scale;
>     Robert>        rec.height *= scale;
>     Robert>        work.x *= scale;
> 
> Eli, is this OK for emacs-27? It will only affect
> display-monitor-attributes-list for people using GTK on multiple
> monitors where one is HiDPI.

Yes, please push to emacs-27, and thanks.

bug#31223: [PATCH] Fix empty/incorrect GTK menus on HiDPI monitors with window scaling factor > 1

[Robert Pluim]

>>>>> On Tue, 07 Jan 2020 18:22:22 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: 31223@debbugs.gnu.org,  tbading@web.de
    >> Date: Tue, 07 Jan 2020 17:15:04 +0100
    >> 
    >> >>>>> On Tue, 17 Dec 2019 15:43:50 +0100, Robert Pluim <rpluim@gmail.com> said:
    Robert> diff --git a/src/xfns.c b/src/xfns.c
    Robert> index 47aa19607f..51a46bd6db 100644
    Robert> --- a/src/xfns.c
    Robert> +++ b/src/xfns.c
    Robert> @@ -5091,6 +5091,8 @@ DEFUN ("x-display-monitor-attributes-list", Fx_display_monitor_attributes_list,
    Robert> #elif defined HAVE_GTK3
    Robert> scale = gdk_screen_get_monitor_scale_factor (gscreen, i);
    Robert> #endif
    Robert> +      rec.x *= scale;
    Robert> +      rec.y *= scale;
    Robert> rec.width *= scale;
    Robert> rec.height *= scale;
    Robert> work.x *= scale;
    >> 
    >> Eli, is this OK for emacs-27? It will only affect
    >> display-monitor-attributes-list for people using GTK on multiple
    >> monitors where one is HiDPI.

    Eli> Yes, please push to emacs-27, and thanks.

Done. Closing.

Robert