-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use a larger Font for xterm during Installation via X Resources #1085
Conversation
I was wondering why you invent such baroque scheme when you can take a base value like 12 and multiply it by the Qt scaling factor to get consistent results. But it looks like you are doing this in shell code and cannot easily multiply by a fractional number. |
I am very sceptical that the Qt scaling factor would be a good multiplier here: The xterm font size doesn't quite fit even with smaller resolutions today, so I really want to start at 10, use 12 for standard resolutions and something larger (right now 14) for HiDPI or resolutions approaching HiDPI. We also have a lower and an upper limit for the Qt scaling factor. There is still room for optimization for those font sizes., of course.
We already shell out to Ruby to calculate that scaling factor; that would not really be the problem. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Allow overriding the calculated XTERM_FONT_SIZE
value
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
✔️ Public Jenkins job #253 successfully finished |
JFYI: simplified testing in inst-sys, directly patching the installer with the code from GitHub:
|
Bugzilla
https://bugzilla.suse.com/show_bug.cgi?id=1211267
Trello
https://trello.com/c/T3uqjJEw/
Problem
For debugging, you can start an xterm during a YaST Qt installation with the
Ctrl
-Shift
-Alt
X
key combination. But since the X11 environment in the inst-sys is minimalistic, and xterm is a very old (almost 40 years) X application, it falls back to built-in very small pixel fonts.That makes that xterm really hard to use even on normal-sized modern displays; on HiDPI displays, it's too tiny to be usable.
Fix
This adds an old-fashioned
~/.Xdefaults
file to set the font size for xterm via X resources:Notice that the comment character in X resource files is '!', not '#' as in most file types.
Even though xterm is one of the oldest X11 applications ever, it received support for modern scalable fonts; see
man xterm
for the resource names.DPI Dependency
This falls back to a font size of 12, but it takes the DPI (which we calculate anyway) into account:
We may have to fine-tune this fallback cascade, but it's much better than the old built-in tiny pixel font.
Overriding from the Environment / at the Boot Prompt
As @lslezak suggested, this also supports setting the value from the environment, which in most cases will mean to set it when booting the installation:
linuxrc
exports all additional parameters to the shell environment.Test
Test in the Development Environment
Just like with the Qt scale factor, invoke the
YaST2.call
script withFAKE_MON_WIDTH_MM
; it will just calculate the values and then exit. Also check/var/log/y2start.log
./var/log/y2start.log
:To actually write the file in that test mode, uncomment the
# add_x11_resources
line and check/root/.Xdefaults
.Test in the Inst-Sys
sshd=1 sshpassword=... startshell=1
YaST2.call
to the VM:scp sh@devhost:/tmp/YaST2.call /tmp
mount -o bind /tmp/YaST2.call /usr/lib/YaST2/startup/YaST2.call
Ctrl
-Shift
-Alt
X
env | grep XTERM
XTERM_FONT_SIZE=10
(or 12 or 14)/var/log/y2start.log
:/root/.Xdefaults
:Caveat: Always Appending
To avoid clobbering somebody's carefully hand-crafted
/root/.Xdefaults
file, this always appends to that file; so calling this repeatedly keeps adding more of those same lines.But that should not matter at all, since we are using the RAM disk in the inst-sys, and this will be invoked only once. Also, later entries overwrite earlier ones, so duplicates don't do any harm.
Background: X Resources
X Resources used to be the tool of choice to configure X clients back in the 1990s and early 2000s. They were used heavily by older toolkits such as the Athena Widgets (the archaic ones that xterm and Tcl/Tk used) and OSF/Motif, but they largely fell out of use with the advent of Qt and Gtk.
The mechanisms how to get an X resource (a single configuration item) to an X client are complicated, and they changed over time. Sometimes you can use an
-xrm
comand line argument. But mostly it was in a number of files that used to be checked one by one.The default location was a file in
/usr/share/X11/app-defaults
that used the class of the application (not the binary name!);XTerm
forxterm
,Emacs
foremacs
etc.; that's the system-wide X resources.Then there was a mind-boggling fallback cascade of other files. One of the oldest of those is a file
.Xdefaults
in the user's home directory.Then somebody realized that it takes a while to read all those files one by one, and the idea was born to store X resources in the X server: That's what
xrdb <filename>
does, and that quickly became the default. Once something is loaded into the X server, you can change the resource files all you want: It will always be ignored. If you want to activate the changes, you have to usexrdb <filename>
again or usexrdb -merge <filename>
(check withxrdb -query
what's loaded into the X server).But in the inst-sys, we don't have that. Or rather, we don't have that anymore; we used to load some few resources like
Xft.dpi
into the X server, but we changed that a while ago: Now we only set some environment variables likeQT_SCALE_FACTOR
.But if we start again to use
xrdb
in the inst-sys, we need to take care to add the values that we are now dynamically adding to/root/.Xdefaults
as well.