freenode/#stumpwm - IRC Chatlog
Search
3:56:22
PuercoPop
loke: that sounds like it could be a problem opening the font. I'll try to reproduce over the weekend. Is setting LC_ALL all that is needed to reproduce?
4:05:53
loke
Also, it doesn't look exactly like an encoding problem. _usually_ at least plain ASCII text works fine even if you get pretty much everything wrong.
4:07:50
PuercoPop
(for example my .xinitrc is exec dbus-launch --exit-with-session /path/to/launch-script
4:08:09
loke
Slightly differently. I didn't use startx when I started things manually. I literally only started Xorg and an Xterm and ran stump from there
4:08:42
loke
With GDM, you get a bunch of other things, but it mostly boils down to startying a dbus-session and some stuf flike that
4:09:36
loke
If it was a font path problem, I'd expect less problems with GDM. Note that everything else I run from the session works fine. It's just text in Stump
4:55:33
PuercoPop
loke: Ok i just tried setting LC_ALL to en_SG.UTF-8 and it isn't enough to reproduce
5:07:30
PuercoPop
loke: maybe you can try w/o a small clx program that opens a window with some text to see if the problem is in StumpWM or below? But you run McCLIM which uses clx outside of StumpWM so it seems unlikely it wouldn't wouldn't manifest there if it was a CLX issue
5:25:33
travis-ci
Change view : https://github.com/stumpwm/stumpwm/compare/f6966cabdf7c...0a104b41bbee
5:38:01
loke
PuercoPop: CLIM doesn't use the Xlib text drawing routines (it uses Xrender, and uses Freetype or cl-ttf for rasterising)
5:38:34
loke
But you might be on to something. If Xlib text drawing is messed up, then you'd likely not notice since nothing uses it... Oh wait... xterm does :-)
6:25:55
PuercoPop
I don't think it is likely to be a combination. Either a wrong assumption on CLX side (or StumpWM) or a configuration issue in the server
6:51:47
loke
the font that gets returned causes that garbage. If I just look up font "fixed" and use that one instead, everything works.
6:56:59
PuercoPop
what was the font that was returned by screen font? Do we need to fix something on StumpWM's side?
6:57:47
PuercoPop
Btw I remember you had an idea to improve the event loop, do you remember what was it?
6:59:09
loke
I seem to recall making some changes to it already, but I forgot how much I actually did
7:03:42
PuercoPop
I thought it was related to epoll, but that would probably mean including iolib as a dependency
7:05:27
loke
Yes. It implemented the ability to send a notification ona side channel (to trigger event processing without Xlib)
7:25:34
loke
I have been playing around with a mainframe emulator, and for that I use an application called x3270 which is an IBM mainframe terminal emulator. It installs a custom font, which is (drumroll) EBCDIC!
7:33:30
loke
When creating the screen object, it tries to open a font called "9x15". If that font doesn't exist, it gets _all_ fonts and uses the first one. In my case, that happens to be "3270" (presumably since it starts with a digit)
7:33:47
loke
The fallback font should be "fixed", since that is the one font that is guaranteed to exist.
7:56:56
loke
That was so interesting that I posted it on Masotodn: https://functional.cafe/@loke/102625562249878048