Re: [dev][st] Solution: UTF-8 needs IBus!
On Tue Apr 26, 2022 at 4:21 PM CDT, Κράκ Άουτ wrote: > Στις 26 Απρ 2022 23:59, ο/η Robert Winkler έγραψε: > > To make a long story short: The input of UTF-8 characters with st needs > > an IBus daemon (standard on Gnome, but not on other window managers such > > as Plasma, dwm, ..). > > > > I added to ~/.config/autostart: > > > > `Ibus-Daemon.desktop` > > > > ~~~ > > [Desktop Entry] > > Name=IBus Daemon > > Type=Application > > Exec=ibus-daemon -drx > > Terminal=false > > ~~~ > > > > Thanks for all your ideas! > > > > Well, UTF-8 or st definitely do not need IBus, I haven't it installed on > my system and everything works fine. Yet if it provides a solution, go > for it. > > Just in case they may help you avoid IBus, my Debian system (systemd > multi-user.targer, no Display Manager, X started by startx) related etc > files: > > cat /etc/default/locale > LANG="el_GR.UTF-8" > > cat /etc/default/keyboard > XKBMODEL="pc105" > XKBLAYOUT="us,gr" > XKBVARIANT="," > XKBOPTIONS="grp:caps_toggle,numpad:mac,grp_led:caps" Well, I don't understand the details; I found this solution by testing all possibilities mentioned on the mailing list or found in duckduckgo searches. The key for me was the different behavior in Gnome. I verified the IBus solution on an armbian64 SBC (who really benefits from suckless programs): 1) Installation and configuration of ibus. 2) Autostart of ibus-daemon. 3) Installation of im-config and defining ibus as default. Maybe it is useful for someone. Best regards, Robert
Re: [dev][st] Solution: UTF-8 needs IBus!
Στις 26 Απρ 2022 23:59, ο/η Robert Winkler έγραψε: To make a long story short: The input of UTF-8 characters with st needs an IBus daemon (standard on Gnome, but not on other window managers such as Plasma, dwm, ..). I added to ~/.config/autostart: `Ibus-Daemon.desktop` ~~~ [Desktop Entry] Name=IBus Daemon Type=Application Exec=ibus-daemon -drx Terminal=false ~~~ Thanks for all your ideas! Well, UTF-8 or st definitely do not need IBus, I haven't it installed on my system and everything works fine. Yet if it provides a solution, go for it. Just in case they may help you avoid IBus, my Debian system (systemd multi-user.targer, no Display Manager, X started by startx) related etc files: cat /etc/default/locale LANG="el_GR.UTF-8" cat /etc/default/keyboard XKBMODEL="pc105" XKBLAYOUT="us,gr" XKBVARIANT="," XKBOPTIONS="grp:caps_toggle,numpad:mac,grp_led:caps"
[dev][st] Solution: UTF-8 needs IBus!
To make a long story short: The input of UTF-8 characters with st needs an IBus daemon (standard on Gnome, but not on other window managers such as Plasma, dwm, ..). I added to ~/.config/autostart: `Ibus-Daemon.desktop` ~~~ [Desktop Entry] Name=IBus Daemon Type=Application Exec=ibus-daemon -drx Terminal=false ~~~ Thanks for all your ideas!
Re: [dev][st][dwm] st UTF-8 works on Gnome, but not on DWM
On Tue, Apr 26, 2022 at 07:48:35PM +0200, Страхиња Радић wrote: > On 22/04/26 05:39, Hadrien Lacour wrote: > > > > Compare the output of env in the two situations. Something I noticed in one > > of > > your mails: you have en_US.UTF-8 in your locale output while here, on > > Gentoo, I > > have en_US.utf8. > > https://wiki.gentoo.org/wiki/Localization/Guide > > The command above lists the suffix in lower case without any hyphens, > > glibc understands both forms of the suffix, many other programs don't. The > > most common example of which is X. So it is best to always use UTF-8 in > > preference to utf8. I see, well, no cigar.
Re: [dev][st][dwm] st UTF-8 works on Gnome, but not on DWM
On 22/04/26 05:39, Hadrien Lacour wrote: > > Compare the output of env in the two situations. Something I noticed in one of > your mails: you have en_US.UTF-8 in your locale output while here, on Gentoo, > I > have en_US.utf8. https://wiki.gentoo.org/wiki/Localization/Guide > The command above lists the suffix in lower case without any hyphens, > glibc understands both forms of the suffix, many other programs don't. The > most common example of which is X. So it is best to always use UTF-8 in > preference to utf8. signature.asc Description: PGP signature
Re: [dev][st][dwm] st UTF-8 works on Gnome, but not on DWM
On Tue, Apr 26, 2022 at 08:20:34AM -0500, Robert Winkler wrote: > Getting closer: I tried the compiled st in different window managers > (thanks for the hint to test the binary in different environments!). > > In Plasma, spectrwm, and dwm, UTF-8 of st does not work. > > But SURPRISE: in Gnome (Wayland, PoP OS! 22.04 LTS), it does! > > This means that the compiled st is working fine, but something strange > is happening related to the environment. But what? > > Anyone has an idea, what could be the difference between Gnome and DWM > with respect to the font encoding? > > Compare the output of env in the two situations. Something I noticed in one of your mails: you have en_US.UTF-8 in your locale output while here, on Gentoo, I have en_US.utf8.
Re: [dev][st][dwm] st UTF-8 works on Gnome, but not on DWM
On 22/04/26 08:20, Robert Winkler wrote: > Anyone has an idea, what could be the difference between Gnome and DWM > with respect to the font encoding? I'm using dwm in X.Org using no display manager (autostart X at login [1]) in Artix Linux and everything works correctly. Setting environment variables correctly greatly depends on your startup "stack", ie. if you are using display manager such as lightdm, sddm... or just logging in through getty (like myself) and autostarting X at login, and also on your login shell. You should study the documentation of every piece of that "stack" thoroughly to determine how exactly to set up your system. Like I mentioned in my previous message, input also depends on how you set it up in X. I'm configuring XKB[2] through the use of setxkbmap(1) by dwm on startup (I use "cool autostart"[3] patch for dwm to do that, though I could have also chosen to do it in $HOME/.xinitrc - again, I don't use a DM). [1]: https://wiki.archlinux.org/title/Xinit#Autostart_X_at_login [2]: https://wiki.archlinux.org/title/X_keyboard_extension [3]: https://dwm.suckless.org/patches/cool_autostart/ signature.asc Description: PGP signature
Re: [dev][st][dwm] st UTF-8 works on Gnome, but not on DWM
On Tue, Apr 26, 2022 at 08:20:34AM -0500, Robert Winkler wrote: > Getting closer: I tried the compiled st in different window managers > (thanks for the hint to test the binary in different environments!). > > In Plasma, spectrwm, and dwm, UTF-8 of st does not work. > > But SURPRISE: in Gnome (Wayland, PoP OS! 22.04 LTS), it does! > > This means that the compiled st is working fine, but something strange > is happening related to the environment. But what? > > Anyone has an idea, what could be the difference between Gnome and DWM > with respect to the font encoding? > > My guess it's still the locale environment somehow (despite the previous posted locale environment values looking good). Maybe the Gnome session thingy sets the proper values, but your script or session file which launches dwm (which spawns st) doesn't have it set? Just a random guess, Good luck, -- Kind regards, Hiltjo
[dev][st][dwm] st UTF-8 works on Gnome, but not on DWM
Getting closer: I tried the compiled st in different window managers (thanks for the hint to test the binary in different environments!). In Plasma, spectrwm, and dwm, UTF-8 of st does not work. But SURPRISE: in Gnome (Wayland, PoP OS! 22.04 LTS), it does! This means that the compiled st is working fine, but something strange is happening related to the environment. But what? Anyone has an idea, what could be the difference between Gnome and DWM with respect to the font encoding?
Re: [dev] [dwm] possible regression in 8806b6e
On Mon, Apr 25, 2022 at 05:38:35PM +0100, Chris Down wrote:
> Hiltjo Posthuma writes:
> > Whats the similar issue exactly? Does this issue also happen when bisecting
> > the
> > same commit (so its a also regression)?
>
> For 8806b6e23793 ("manage: propertynotify: Reduce cost of unused size
> hints"), the issue is that c->isfixed may not be set early, which might
> affect whether we intend to make the window floating or not.
>
> For bece862a0fc4 ("manage: For isfloating/oldstate check/set, ensure trans
> client actually exists"), the issue is that some non-SDL client which
> actually _should_ float have WM_TRANSIENT_FOR set to the root window. I
> posted about this on hackers@ a few weeks ago.[0]
>
> For 8806b6e23793, I think the change I suggested should be sufficient, but
> would like to get confirmation from Ethan first and then will submit it as a
> proper patch.
>
Yes please
> For bece862a0fc4, I think it might just need to be reverted unless more
> specific logic can be applied, since it seems over the top to add more logic
> just to reliably distinguish SDL clients from other affected clients.
>
I've reverted the patch. It can be reworked to fix both issues (the regression
and the initial
reason it was posted) maybe.
> In both cases the symptoms are that some subset of clients may not float
> when they should, but in the case of 8806b6e23793 it's "fixed" windows where
> the dimensions are fixed in size hints, and in the case of bece862a0fc4 it's
> windows with WM_TRANSIENT_FOR set to the root window (like the gpg2
> pinentry).
>
> 0: https://lists.suckless.org/hackers/2203/18220.html
--
Kind regards,
Hiltjo
signature.asc
Description: PGP signature
Re: [dev] [dwm] possible regression in 8806b6e
Ethan Marshall writes: Completely fixed. All affected windows now behave as they did before the patch - so, problem solved on my end. Thanks for all your help Chris. Excellent, thanks for getting back. I've submitted it as a proper patch.
Re: [dev][st] UTF-8 works on debian, but not on PopOS Ubuntu
Στις 26 Απρ 2022 06:49, ο/η Robert Winkler έγραψε: With the risk of annoying the experts (but lacking UTF-8 is a show stopper for me, since I write a lot in Spanish and German..). I compiled the same st code on Debian 11 (Bullseye) and Pop OS! (Ubuntu 21.10). On Debian, UTF-8 works fine, on Pop OS!, with the same keyboard, it doesn't. In both cases, UTF-8 works in lxterminal. The Liberation Mono (Regular) font, defined in `config.h` is installed. LC_CTYPE is set correctly to "en_US.UTF-8" The terminfo entries are added (tic -sx st.info) There are no warnings or errors during the compilation: ~~~ root@pop-os /h/r/d/n/s/st# make clean; make install rm -f st st.o x.o st-0.8.5.tar.gz c99 -I/usr/X11R6/include `pkg-config --cflags fontconfig` `pkg-config --cflags freetype2` -DVERSION=\"0.8.5\" -D_XOPEN_SOURCE=600 -O1 -c st.c c99 -I/usr/X11R6/include `pkg-config --cflags fontconfig` `pkg-config --cflags freetype2` -DVERSION=\"0.8.5\" -D_XOPEN_SOURCE=600 -O1 -c x.c c99 -o st st.o x.o -L/usr/X11R6/lib -lm -lrt -lX11 -lutil -lXft `pkg-config --libs fontconfig` `pkg-config --libs freetype2` mkdir -p /usr/local/bin cp -f st /usr/local/bin chmod 755 /usr/local/bin/st mkdir -p /usr/local/share/man/man1 sed "s/VERSION/0.8.5/g" < st.1 > /usr/local/share/man/man1/st.1 chmod 644 /usr/local/share/man/man1/st.1 tic -sx st.info 7 entries written to /etc/terminfo Please see the README file regarding the terminfo entry of st. ~~~ If I call surf from st, the unicode characters work well. Isn't that an indicator that the configuration cannot be that wrong? Is there a systematic troubleshooting method? Of course, I could re-install the computer with Debian and try again compiling st, but there should be an easier way ... Best regards, Robert Have you tried copying the compiled st executable from Debian to Pop and running it in Pop? I'd also try the opposite, copy st from Pop to Debian. That way you can check if the compiled executable (the chain to produce the binary) or the environmental variables affect UTF-8.
Re: [dev][st] UTF-8 works on debian, but not on PopOS Ubuntu
Hi Robert, > LC_CTYPE is set correctly to "en_US.UTF-8" Set how? > I compiled the same st code on Debian 11 (Bullseye) and Pop OS! (Ubuntu > 21.10). On Debian, UTF-8 works fine, on Pop OS!, with the same keyboard, > it doesn't. In both cases, UTF-8 works in lxterminal. Could you explain your actual test process? > If I call surf from st, the unicode characters work well. Isn't that an > indicator that the configuration cannot be that wrong? Not really, because a web page encoding is a content property and should be specified in the HTTP headers. > Of course, I could re-install the computer with Debian and try again > compiling st, but there should be an easier way ... I doubt this would solve the issue that seems to be related to the combination of st and Pop OS!, it works on Deian.
