From: martin rudalics <rudalics@gmx.at>
To: cscott@cscott.net
Cc: 20619@debbugs.gnu.org
Subject: bug#20619: Another HiDPI issue
Date: Thu, 19 May 2016 14:55:04 +0200 [thread overview]
Message-ID: <573DB7A8.5060805@gmx.at> (raw)
In-Reply-To: <CAHD_y+ZJpz9DadEWP1R4JeDi2NyfSDNt3oG5GT05Tczpcgud9w@mail.gmail.com>
> 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
next prev parent reply other threads:[~2016-05-19 12:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-20 18:20 bug#20619: 24.5; Pop-up menus clipped on HiDPI (Gtk3/X11) Michael Droettboom
2015-05-23 12:06 ` Jan Djärv
2016-05-11 15:02 ` bug#20619: Another HiDPI issue C. Scott Ananian
2016-05-16 8:20 ` martin rudalics
2016-05-16 18:31 ` C. Scott Ananian
2016-05-18 7:00 ` martin rudalics
2016-05-18 12:20 ` C. Scott Ananian
[not found] ` <CAHD_y+aqKdHYBucR3VkwduiVWDex4oCmX6EeYYkoKC+Fb=RoSA@mail.gmail.com>
[not found] ` <CAHD_y+Z1D37uNOcnrn2SaxSO9bksEOV_Ni0QhZ2fE1nLvMRD+g@mail.gmail.com>
2016-05-18 12:24 ` C. Scott Ananian
2016-05-19 12:55 ` martin rudalics [this message]
2016-12-22 15:33 ` bug#20619: Improving HiDPI experience with emacs Eugen Dedu
2016-12-23 20:30 ` bug#20619: Scrollbars Eugen Dedu
2016-12-24 7:56 ` Eli Zaretskii
2016-12-27 22:45 ` Eugen Dedu
2016-12-28 15:41 ` Eli Zaretskii
2016-12-28 16:35 ` Eugen Dedu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=573DB7A8.5060805@gmx.at \
--to=rudalics@gmx.at \
--cc=20619@debbugs.gnu.org \
--cc=cscott@cscott.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.