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

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

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))



Reply | Threaded
Open this post in threaded view
|

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.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Thomas Schneider <[hidden email]>
> 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.



Reply | Threaded
Open this post in threaded view
|

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

Thomas Schneider
Eli Zaretskii <[hidden email]> writes:

>> From: Thomas Schneider <[hidden email]>
>> 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.

s.png (77K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Thomas Schneider <[hidden email]>
> Cc: [hidden email]
> 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?



Reply | Threaded
Open this post in threaded view
|

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

Thomas Schneider
Eli Zaretskii <[hidden email]> writes:

>> From: Thomas Schneider <[hidden email]>
>> Cc: [hidden email]
>> 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.



Reply | Threaded
Open this post in threaded view
|

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?



Reply | Threaded
Open this post in threaded view
|

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

Noam Postavsky
In reply to this post by Thomas Schneider
Thomas Schneider <[hidden email]> 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).



Reply | Threaded
Open this post in threaded view
|

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

Thomas Schneider
In reply to this post by Eli Zaretskii
Eli Zaretskii <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Thomas Schneider <[hidden email]>
> Cc: [hidden email]
> 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.



Reply | Threaded
Open this post in threaded view
|

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

Noam Postavsky
In reply to this post by Thomas Schneider
merge 23672 28106 31223
quit

Thomas Schneider <[hidden email]> writes:

> Eli Zaretskii <[hidden email]> writes:
>
>>> From: Thomas Schneider <[hidden email]>
>>> 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.




Reply | Threaded
Open this post in threaded view
|

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

Tobias Bading-2
In reply to this post by Thomas Schneider
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


0001-Fix-empty-incorrect-GTK-menus-on-HiDPI-monitors.patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Tobias Bading-2
On 28.11.19 09:20, Robert Pluim wrote:
 >>>>>> On Wed, 27 Nov 2019 17:03:32 +0100, Tobias Bading
<[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Noam Postavsky
In reply to this post by Tobias Bading-2
Tobias Bading <[hidden email]> 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).



Reply | Threaded
Open this post in threaded view
|

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

Robert Pluim
In reply to this post by Robert Pluim
>>>>> On Thu, 28 Nov 2019 10:44:08 +0100, Robert Pluim <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Robert Pluim <[hidden email]>
> Date: Mon, 02 Dec 2019 11:35:03 +0100
> Cc: [hidden email]
>
> 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.



Reply | Threaded
Open this post in threaded view
|

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

Robert Pluim
In reply to this post by Thomas Schneider
>>>>> On Mon, 02 Dec 2019 17:53:16 +0200, Eli Zaretskii <[hidden email]> said:

    >> From: Robert Pluim <[hidden email]>
    >> Date: Mon, 02 Dec 2019 11:35:03 +0100
    >> Cc: [hidden email]
    >>
    >> 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