bug#20619: 24.5; Pop-up menus clipped on HiDPI (Gtk3/X11)

bug#20619: 24.5; Pop-up menus clipped on HiDPI (Gtk3/X11)

[Michael Droettboom]

If in HiDPI mode on Linux [1] the popup menus are constrained to the
upper left quadrant of the screen and are not opened near the mouse
cursor. For example, 'C-mouse-1' in the lower-right hand quadrant opens
an empty menu. 'C-mouse-1' in the upper-right hand quadrant opens a
menu, but not in the correct location.

[1] This mode is set automatically under Gnome, or may get set manually
with:

gsettings set org.gnome.desktop.interface scaling-factor 2

A workaround, which may help to diagnose the bug, is to start emacs
using:

GDK_SCALE=0.5 emacs

Other Gtk3 applications (gnome-terminal, nautilus) so not seem to
exhibit this behavior under the same conditions.



In GNU Emacs 24.5.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.16.2)
of 2015-04-22 on buildhw-08.phx2.fedoraproject.org
Windowing system distributor `Fedora Project', version 11.0.11701000
System Description: Fedora release 23 (Rawhide)

Configured using:
`configure --build=x86_64-redhat-linux-gnu
--host=x86_64-redhat-linux-gnu --program-prefix=
--disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
--libexecdir=/usr/libexec --localstatedir=/var
--sharedstatedir=/var/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
--with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=gtk3
--with-gpm=no build_alias=x86_64-redhat-linux-gnu
host_alias=x86_64-redhat-linux-gnu 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector-strong --param=ssp-buffer-size=4
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-m64 -mtune=generic' LDFLAGS=-Wl,-z,relro'

Important settings:
value of $LC_CTYPE: en_US.utf8
value of $LANG: en_US.utf8
locale-coding-system: utf-8-unix

bug#20619: 24.5; Pop-up menus clipped on HiDPI (Gtk3/X11)

[Jan Djärv]

Hi.

Den 2015-05-20 20:20, Michael Droettboom skrev:
>
> If in HiDPI mode on Linux [1] the popup menus are constrained to the
> upper left quadrant of the screen and are not opened near the mouse
> cursor. For example, 'C-mouse-1' in the lower-right hand quadrant opens
> an empty menu. 'C-mouse-1' in the upper-right hand quadrant opens a
> menu, but not in the correct location.
>
> [1] This mode is set automatically under Gnome, or may get set manually
> with:
>
> gsettings set org.gnome.desktop.interface scaling-factor 2
>
> A workaround, which may help to diagnose the bug, is to start emacs
> using:
>
> GDK_SCALE=0.5 emacs

This is a huge undertaking, that requires changes in Emacs all over the place. 
  Coordinates and sizes are used in many places.
I'm not sure its worth it, as this Gnome thing is a bad way to scale 
applications (it requires applications to conform to Gtk+).
KDE does something different for example.  So I'm guessing something better 
will emerge.

>
> Other Gtk3 applications (gnome-terminal, nautilus) so not seem to
> exhibit this behavior under the same conditions.

Emacs is not a Gtk3 application, ut just uses some of its widgets.
Its more of a raw X11/Gtk3 hybrid.

	Jan D.

>
>
>
> In GNU Emacs 24.5.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.16.2)
> of 2015-04-22 on buildhw-08.phx2.fedoraproject.org
> Windowing system distributor `Fedora Project', version 11.0.11701000
> System Description: Fedora release 23 (Rawhide)
>
> Configured using:
> `configure --build=x86_64-redhat-linux-gnu
> --host=x86_64-redhat-linux-gnu --program-prefix=
> --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
> --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
> --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
> --libexecdir=/usr/libexec --localstatedir=/var
> --sharedstatedir=/var/lib --mandir=/usr/share/man
> --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
> --with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=gtk3
> --with-gpm=no build_alias=x86_64-redhat-linux-gnu
> host_alias=x86_64-redhat-linux-gnu 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g
> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4
> -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -m64 -mtune=generic' LDFLAGS=-Wl,-z,relro'
>
> Important settings:
> value of $LC_CTYPE: en_US.utf8
> value of $LANG: en_US.utf8
> locale-coding-system: utf-8-unix
>
>
>
>

bug#20619: Another HiDPI issue

[C. Scott Ananian]

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

In addition to the pop-up menus being misplaced, on my machine
(debian/testing, HiDPI=2, emacs 24.5.1) I'm seeing the initial window sizes
being much too wide.  The scaling from columns from font-size seems to be
broken, because when I resize the window emacs claims the window is "80x24"
but in reality it is much wider (I'm guessing twice as wide).
  --scott

-- 
                         ( http://cscott.net/ )

[-- Attachment #2: Type: text/html, Size: 597 bytes --]

bug#20619: Another HiDPI issue

[martin rudalics]

 > In addition to the pop-up menus being misplaced, on my machine
 > (debian/testing, HiDPI=2, emacs 24.5.1) I'm seeing the initial window sizes
 > being much too wide.  The scaling from columns from font-size seems to be
 > broken, because when I resize the window emacs claims the window is "80x24"
 > but in reality it is much wider (I'm guessing twice as wide).

Did you ever try the patch submitted to this thread?

martin

bug#20619: Another HiDPI issue

[C. Scott Ananian]

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

I read the patch and did not see anywhere where it affected the main window
size. The changes appear to be isolated to the position of popups; in
particular the only functions modified are `xg_show_tooltip` and
`create_and_show_popup_menu`.  I am happy to try a patch if it will address
the main window size issues I am seeing.
  --scott
​

[-- Attachment #2: Type: text/html, Size: 375 bytes --]

bug#20619: Another HiDPI issue

[martin rudalics]

 > I read the patch and did not see anywhere where it affected the main window
 > size. The changes appear to be isolated to the position of popups; in
 > particular the only functions modified are `xg_show_tooltip` and
 > `create_and_show_popup_menu`.  I am happy to try a patch if it will address
 > the main window size issues I am seeing.

Ryan Prior has written a patch for the original problem posted in this
thread.  Unfortunately, Michael Droettboom (the poster of the problem)
never responded and neither did other persons who reported similar
problems.  In December, for example, David Christiansen promised to test
Ryan's patch as soon as he would get home from honeymoon.  Apparently he
never did ...

Since you are able to reproduce the problem, it would have been a nice
gesture if you applied the patch and tested whether it resolves the
original problem.  Maybe this way you could have provided sufficient
motivation for Ryan to investigate the problem you see too.  As it
stands, it's virtually impossible to convince HiDPI users to test Ryan's
patch and we very likely lost another contributor.

martin

bug#20619: Another HiDPI issue

[C. Scott Ananian]

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

It's not like it's hard to reproduce: download gnome-tweak-tool and set
your scaling factor to 2.  It doesn't require any special hardware.

[-- Attachment #2: Type: text/html, Size: 171 bytes --]

bug#20619: Another HiDPI issue

[C. Scott Ananian]

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

What would be *more* useful, instead of guilt-tripping contributors, is to
offer some technical advice on the issue: where my program is likely to be
fine, what part of the code I might consider reading, and useful insight at
all.  Then you might motivate me to scratch my own itch and *gain* a
contributor.  Instead you are in the process of losing two.
On May 18, 2016 8:20 AM, "C. Scott Ananian" <cscott@cscott.net> wrote:

It's not like it's hard to reproduce: download gnome-tweak-tool and set
your scaling factor to 2.  It doesn't require any special hardware.

[-- Attachment #2: Type: text/html, Size: 836 bytes --]

bug#20619: Another HiDPI issue

[martin rudalics]

 > It's not like it's hard to reproduce: download gnome-tweak-tool and set
 > your scaling factor to 2.  It doesn't require any special hardware.

ISTR that Glenn already proposed something similar.  But I don't use
GNOME.  I use xfce and spent an entire afternoon to make xfce accept the
resolution of my display.  The only things I remember about that is that
there's hardly anything useful to be found about this issue on the Web
and that I had to resort to some non-standard means to have my settings
restored in subsequent sessions.  I'm simply too afraid to break these
settings by simulating a fictitious high resolution display.

 > What would be *more* useful, instead of guilt-tripping contributors, is to
 > offer some technical advice on the issue: where my program is likely to be
 > fine, what part of the code I might consider reading, and useful insight at
 > all.  Then you might motivate me to scratch my own itch and *gain* a
 > contributor.  Instead you are in the process of losing two.

Offering technical advice on this issue is not easy for me.  In the
first place I've so far not been able to understand what the HiDPI
scaling issue is all about.  I presume that font scaling is left to the
application which means for Emacs that users who have set their HiDPI
scaling factor to two usually will select a default font twice the usual
size.  Icon scaling is presumably also left to the application which
probabaly means that the Emacs tool bar on a HiDPI scaled display looks
very tiny.  Are these assumptions correct?

If so, scaling probably affects only the sizes and position of windows
including subwindows and widgets for menus, scrollbars and tooltips
needed to make the appearance of Emacs frames coherent.  I said
"probably" because the bug descriptions I've red so far do not allow me
to draw a precise conclusion.  Maybe we should resolve that issue first
(see also my questions to Ryan in the thread of bug#20619): Which
behaviors are reproducible under which desktop environments, toolkits
etc.

Now in the thread on bug#20619 Jan said that

   This is a huge undertaking, that requires changes in Emacs all over
   the place.  Coordinates and sizes are used in many places.

But IIUC we do have to identify and change only those places where Emacs
passes/receives coordinates to/from the operating system, window
manager, or toolkit.  Internally, Emacs will proceed to think in its own
coordinates.  And apparently we have to do that only for the gtk build.
Do these assumptions make sense?

Now IIUC again Ryan has already provided a solution for the positioning
of popup menus and tooltips.  IMO we would have to first check whether
his approach to use xg_scale_x_y_with_widget is correct and popup menus
and tooltips are placed correctly wrt a (probably only fictitiously)
correctly positioned frame.  If so we can see whether that function can
be used for the remaining elements as well.  WDYT?

martin

bug#20619: Improving HiDPI experience with emacs

[Eugen Dedu]

Hi,

I have just enabled hidpi on my screen and noticed that emacs has 
several issues I would really like to see them fixed, since I use it 
extensively.  (For those interested, I also wrote yesterday a page about 
my experiences at http://eugen.dedu.free.fr/docs/hidpi.html.)

I do not use GNOME, but awesome.  I just set GDK_SCALE=2 to have 
hidpi-aware applications, and this works on several applications.

Everyone can test with "GDK_SCALE=X emacs", with X=1 (for normal screen, 
default value) and X=2 for hidpi.

Is there any emacs developer wanting to fix this behaviour?  I can test 
patches if needed (hope it is not harder than other applications).

I use emacs 25.1.1 on debian.

Best regards,
-- 
Eugen

bug#20619: Scrollbars

[Eugen Dedu]

So I have successfully compiled emacs 25.1.1 to make tests.

I applied the patch given in message #13, but it works partially, I will 
discuss about it later.

Now, to advance emacs support for HIDPI I would like to fix the 
scrollbar.  Do all people here agree that the scrollbar has a width 
twice as normal?  The reason is that in src/gtkutil.c there is this code:

int
xg_get_default_scrollbar_width (void)
{
   return scroll_bar_width_for_theme * xg_get_gdk_scale ();
}

where xg_get_gdk_scale returns GDK_SCALE variable, i.e. 2 in general.

If I replace with:
   return scroll_bar_width_for_theme;
the scrollbar is shown correctly.

This change was made by 
https://github.com/emacs-mirror/emacs/commit/c0055ff5b03c9121ab5bf752496b09416f0f0a7d. 
  I think there was an error there, or perhaps in the mean time (since 
May 2015) GTK has changed in a way so that scrollbars are taken into 
account.

Anyway, using "GTK_SCALE=2 emacs" shows correctly the scrollbar with my 
proposition.

Note that GDK_DPI_SCALE is only for font, AFAIU from 
https://developer.gnome.org/gtk3/stable/gtk-x11.html.

What do you think?  Would you commit such a modification?

I would like to look into other issues as well.

bug#20619: Scrollbars

[Eli Zaretskii]

> From: Eugen Dedu <eugen.dedu@univ-fcomte.fr>
> Date: Fri, 23 Dec 2016 21:30:17 +0100
> 
> Now, to advance emacs support for HIDPI I would like to fix the 
> scrollbar.  Do all people here agree that the scrollbar has a width 
> twice as normal?  The reason is that in src/gtkutil.c there is this code:
> 
> int
> xg_get_default_scrollbar_width (void)
> {
>    return scroll_bar_width_for_theme * xg_get_gdk_scale ();
> }
> 
> where xg_get_gdk_scale returns GDK_SCALE variable, i.e. 2 in general.
> 
> If I replace with:
>    return scroll_bar_width_for_theme;
> the scrollbar is shown correctly.
> 
> This change was made by 
> https://github.com/emacs-mirror/emacs/commit/c0055ff5b03c9121ab5bf752496b09416f0f0a7d. 
>   I think there was an error there, or perhaps in the mean time (since 
> May 2015) GTK has changed in a way so that scrollbars are taken into 
> account.

What is your version of GTK?  That commit points to a bug report
(bug#20432), so this change is not a mistake, it did fix a real
problem with scroll bars.  We could make it conditional on the GTK
version, though.  The bug report mentions a specific GTK version.

> Note that GDK_DPI_SCALE is only for font, AFAIU from 
> https://developer.gnome.org/gtk3/stable/gtk-x11.html.

The code you mention doesn't use GDK_DPI_SCALE.

> What do you think?  Would you commit such a modification?

I don't think we can simply revert the change in question, but maybe
we could use different code based on GTK version.

> I would like to look into other issues as well.

Thank you!  I see bugs 20432, 21469, and 18429 that might be relevant.

bug#20619: Scrollbars

[Eugen Dedu]

On 24/12/16 08:56, Eli Zaretskii wrote:
>> From: Eugen Dedu <eugen.dedu@univ-fcomte.fr>
>> Date: Fri, 23 Dec 2016 21:30:17 +0100
>>
>> Now, to advance emacs support for HIDPI I would like to fix the
>> scrollbar.  Do all people here agree that the scrollbar has a width
>> twice as normal?  The reason is that in src/gtkutil.c there is this code:
>>
>> int
>> xg_get_default_scrollbar_width (void)
>> {
>>    return scroll_bar_width_for_theme * xg_get_gdk_scale ();
>> }
>>
>> where xg_get_gdk_scale returns GDK_SCALE variable, i.e. 2 in general.
>>
>> If I replace with:
>>    return scroll_bar_width_for_theme;
>> the scrollbar is shown correctly.
>>
>> This change was made by
>> https://github.com/emacs-mirror/emacs/commit/c0055ff5b03c9121ab5bf752496b09416f0f0a7d.
>>   I think there was an error there, or perhaps in the mean time (since
>> May 2015) GTK has changed in a way so that scrollbars are taken into
>> account.
>
> What is your version of GTK?  That commit points to a bug report
> (bug#20432), so this change is not a mistake, it did fix a real
> problem with scroll bars.  We could make it conditional on the GTK
> version, though.  The bug report mentions a specific GTK version.

I use gtk 3.22.5.

To reproduce the exact environment when that commit was made, I pulled 
the repository at the commit right before that change and compiled it. 
I had one compile error that I fixed with an #undef, and another one:
make[1]: *** [bootstrap-emacs] Segmentation fault
which I have not tried to fix.

>> Note that GDK_DPI_SCALE is only for font, AFAIU from
>> https://developer.gnome.org/gtk3/stable/gtk-x11.html.
>
> The code you mention doesn't use GDK_DPI_SCALE.

Indeed.  I wrote this because in the bug 20432 which the commit fixed it 
was mentioned GDK_DPI_SCALE too.

>> What do you think?  Would you commit such a modification?
>
> I don't think we can simply revert the change in question, but maybe
> we could use different code based on GTK version.

If I make an #ifdef with gtk 3.22, is that fine to do the commit? 
Everyone can test with a gtk-enabled emacs simply using "GDK_SCALE=2 emacs".

>> I would like to look into other issues as well.
>
> Thank you!  I see bugs 20432, 21469, and 18429 that might be relevant.

I have looked at them, but I think the right thing to do is just to fix 
using conditionals, things have changed in the last 1-1.5 years (when 
those bugs were written) it seems.

-- 
Eugen

bug#20619: Scrollbars

[Eli Zaretskii]

> Cc: 20619@debbugs.gnu.org
> From: Eugen Dedu <eugen.dedu@univ-fcomte.fr>
> Date: Tue, 27 Dec 2016 23:45:24 +0100
> 
> > What is your version of GTK?  That commit points to a bug report
> > (bug#20432), so this change is not a mistake, it did fix a real
> > problem with scroll bars.  We could make it conditional on the GTK
> > version, though.  The bug report mentions a specific GTK version.
> 
> I use gtk 3.22.5.
> [...]
> >> What do you think?  Would you commit such a modification?
> >
> > I don't think we can simply revert the change in question, but maybe
> > we could use different code based on GTK version.
> 
> If I make an #ifdef with gtk 3.22, is that fine to do the commit? 

Only as the last resort, IMO.  I'd be much happier if someone could
explain how come this is/was a problem for GTK+ v3.16.2, but not for
v3.22.5.  Is it possible to ask someone on some GTK+ forum?  Or maybe
someone who reads this can explain that?

> Everyone can test with a gtk-enabled emacs simply using "GDK_SCALE=2 emacs".

I can't, sadly.

Thanks.

bug#20619: Scrollbars

[Eugen Dedu]

On 28/12/16 16:41, Eli Zaretskii wrote:
>> Cc: 20619@debbugs.gnu.org
>> From: Eugen Dedu <eugen.dedu@univ-fcomte.fr>
>> Date: Tue, 27 Dec 2016 23:45:24 +0100
>>
>>> What is your version of GTK?  That commit points to a bug report
>>> (bug#20432), so this change is not a mistake, it did fix a real
>>> problem with scroll bars.  We could make it conditional on the GTK
>>> version, though.  The bug report mentions a specific GTK version.
>>
>> I use gtk 3.22.5.
>> [...]
>>>> What do you think?  Would you commit such a modification?
>>>
>>> I don't think we can simply revert the change in question, but maybe
>>> we could use different code based on GTK version.
>>
>> If I make an #ifdef with gtk 3.22, is that fine to do the commit?
>
> Only as the last resort, IMO.  I'd be much happier if someone could
> explain how come this is/was a problem for GTK+ v3.16.2, but not for
> v3.22.5.  Is it possible to ask someone on some GTK+ forum?  Or maybe
> someone who reads this can explain that?

Just for information, I looked also in the NEWS file of GTK and have not 
seen anything about the scrolllbars between 3.16.2 and 3.22.5.

-- 
Eugen