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