Re: [dev] Regarding dwm and st logo being removed
2022-04-28 9:38 GMT+02:00, Страхиња Радић : > In my opinion, dark mode is unnecessary and favored by mainstream > "webdevs". > Divide et impera (light vs dark mode) is the easiest solution they could come up for soothing the look'n'feel hell in which desktop vendors throwed themselves into.
Re: [dev][st] Solution: UTF-8 needs IBus!
On April 28, 2022 12:36:34 PM CDT, Greg Minshall wrote:
>Robert,
>
>i wonder if this SO exchange might be familiar:
>
>https://unix.stackexchange.com/questions/368803/bash-seems-to-be-in-special-mode
>
>
>i just ran into something similar, where typing into the shell gave odd
>characters (or, the "(arg: 1)" prompt). in this case, for *me*, (*)
>
>bash apollo2 (master): {35664} bind -v | grep convert-meta
>set convert-meta on
>
>was an indicator of what was wrong. in my ~/.inputrc i had
>
>set convert-meta on
>
>(for some reason lost in history.) taking this line out fixed *my*
>problem with (newly invoked) shells.
>
>for completeness, i *also* had a problem with emacs, which seems to be
>because in my .bashrc, i had
>
>export XMODIFIERS=@im=ibus
>
>
>changing that to
>
>export XMODIFIERS=@im=none
>
>made emacs happy.
>
>cheers, Greg
>
>(*) causing X11's "compose feature" (which, through keyd(8), is how i'm
>generating these non-ASCII characters) to send characters like ó to,
>e.g., cat(1), worked. my problems seemed to be just with the shell and
>emacs.
>
Sorry, I cannot reproduce the issues with Emacs. Since an accident with a
broken beer bottle I need to use an ergonomic Editor: vim (the Editor of the
beast ;-)).
Re: [dev] Regarding dwm and st logo being removed
On Thu, 28 Apr 2022 18:14:14 +0200 Hiltjo Posthuma wrote: Dear Hiltjo, > Sure I don't mind you added them back. > With the inverted colors they are visible here. alright, cool. :) Thanks also for adding the dark theme. With best regards Laslo
Re: [dev] [st] UTF-8 not working
On 22/04/28 01:44, Robert Winkler wrote: > > usually, I am using the fish https://www.youtube.com/watch?v=8AQobpqySAU signature.asc Description: PGP signature
Re: [dev] [st] UTF-8 not working
On Thu Apr 28, 2022 at 11:48 AM CDT, Страхиња Радић wrote: > On 22/04/15 07:08, Robert Winkler wrote: > > Hi, according to the st Status, UTF-8 should be working. Much needed for > > multilingual typing with ú, ü, ß, µ, ¿ etc. > > However, I only get 00e9 if I type é; anything, I need to specify in > > config.h? > > Best, Robert > > Liks I said, I only use: > > - login through getty (no display manager like lightdm, sddm, gdm...) > - no desktop environment, pure X.Org > - dwm as a window manager > - X.Org's native XKB configured with: > setxkbmap -layout us,rs -option grp:alt_shift_toggle > which is executed by dwm on startup > > and I can input various characters in Cyrillic, as well as color emoji and > other symbols using my own script[1]. > > May I ask what shell are you using inside st? The only problem I noticed so > far > with my script, which uses xdotool(1) to type characters, is when I am using > it > while st is specifically executing mksh as a shell. With bash, dash and zsh > emoji are inserted correctly. This is undoubtedly some misconfiguration of > mksh > on my part, which I have yet to figure out in detail. > > However, when I type ordinary text, regardless if it is using Cyrillic > characters, using Serbian keyboard, or those characters you listed in your > original message, using Spanish keyboard, they are entered and displayed > correctly, even in mksh. I have captured a screenshot[2] as a proof of > concept. > > In the first line in the screenshot, I have typed a command to configure XKB: > > setxkbmap -layout us,es -option grp:alt_shift_toggle > > In the second line, I have typed characters after switching to Spanish layout > by pressing left Alt+Shift. > > In the third line, I have typed the characters I used to get characters in > the > previous line, after switching back to US layout. > > The other screenshot[3] demonstrates pasting a text containing color emoji > from > a web page into Bash running under st. I do have libxft-bgra patch for Xft > installed through an AUR package to show color emoji. > > > [1]: https://git.sr.ht/~strahinja/dwm/tree/master/item/pickchar > [2]: https://i.imgur.com/yWd2nPd.png > [3]: https://i.imgur.com/7yTYHUY.png > [4]: https://aur.archlinux.org/libxft-bgra.git usually, I am using the fish
Re: [dev] [st] UTF-8 not working
On 22/04/28 06:48, Страхиња Радић wrote: > May I ask what shell are you using inside st? The only problem I noticed so > far > with my script, which uses xdotool(1) to type characters, is when I am using > it > while st is specifically executing mksh as a shell. With bash, dash and zsh > emoji are inserted correctly. This is undoubtedly some misconfiguration of > mksh > on my part, which I have yet to figure out in detail. After some investigation, I discovered the following paragraph in mksh FAQ[1]: > The shell’s utf8-mode before mksh R60 supported only the BMP (Basic > Multilingual Plane) of UCS and mapped raw (extended ASCII) octets, i.e. these > which are not valid UTF-8 BMP codepoints) into the U+EF80‥U+EFFF range, which > is allocated at the CSUR for this purpose. (It otherwise lies in the PUA; > however, there is ambiguity if encountering those UTF-8-encoded, so it > changed > for R60.) The Arithmetic expressions and CAVEATS sections in mksh(1) contain > more details about encoding and mapping. > > As of R60, utf8-mode maps “raw octets” to U-1080‥U-10FF, which is > outside the UCS and therefore collision-free. There’s work underway to make > the > shell support the full 21-bit UCS range for R60. Since I'm currently using mksh R59, that part of the mystery is solved as well. **Definitive conclusion: st does not need GNOME, ibus or other bloat (aside from good old native X.Org bloat itself) to support UTF-8 input/output.** [1]: http://www.mirbsd.org/mksh-faq.htm#posix-mode signature.asc Description: PGP signature
Re: [dev][st] Solution: UTF-8 needs IBus!
Robert,
i wonder if this SO exchange might be familiar:
https://unix.stackexchange.com/questions/368803/bash-seems-to-be-in-special-mode
i just ran into something similar, where typing into the shell gave odd
characters (or, the "(arg: 1)" prompt). in this case, for *me*, (*)
bash apollo2 (master): {35664} bind -v | grep convert-meta
set convert-meta on
was an indicator of what was wrong. in my ~/.inputrc i had
set convert-meta on
(for some reason lost in history.) taking this line out fixed *my*
problem with (newly invoked) shells.
for completeness, i *also* had a problem with emacs, which seems to be
because in my .bashrc, i had
export XMODIFIERS=@im=ibus
changing that to
export XMODIFIERS=@im=none
made emacs happy.
cheers, Greg
(*) causing X11's "compose feature" (which, through keyd(8), is how i'm
generating these non-ASCII characters) to send characters like ó to,
e.g., cat(1), worked. my problems seemed to be just with the shell and
emacs.
Re: [dev] [st] UTF-8 not working
On 22/04/15 07:08, Robert Winkler wrote: > Hi, according to the st Status, UTF-8 should be working. Much needed for > multilingual typing with ú, ü, ß, µ, ¿ etc. > However, I only get 00e9 if I type é; anything, I need to specify in > config.h? > Best, Robert Liks I said, I only use: - login through getty (no display manager like lightdm, sddm, gdm...) - no desktop environment, pure X.Org - dwm as a window manager - X.Org's native XKB configured with: setxkbmap -layout us,rs -option grp:alt_shift_toggle which is executed by dwm on startup and I can input various characters in Cyrillic, as well as color emoji and other symbols using my own script[1]. May I ask what shell are you using inside st? The only problem I noticed so far with my script, which uses xdotool(1) to type characters, is when I am using it while st is specifically executing mksh as a shell. With bash, dash and zsh emoji are inserted correctly. This is undoubtedly some misconfiguration of mksh on my part, which I have yet to figure out in detail. However, when I type ordinary text, regardless if it is using Cyrillic characters, using Serbian keyboard, or those characters you listed in your original message, using Spanish keyboard, they are entered and displayed correctly, even in mksh. I have captured a screenshot[2] as a proof of concept. In the first line in the screenshot, I have typed a command to configure XKB: setxkbmap -layout us,es -option grp:alt_shift_toggle In the second line, I have typed characters after switching to Spanish layout by pressing left Alt+Shift. In the third line, I have typed the characters I used to get characters in the previous line, after switching back to US layout. The other screenshot[3] demonstrates pasting a text containing color emoji from a web page into Bash running under st. I do have libxft-bgra patch for Xft installed through an AUR package to show color emoji. [1]: https://git.sr.ht/~strahinja/dwm/tree/master/item/pickchar [2]: https://i.imgur.com/yWd2nPd.png [3]: https://i.imgur.com/7yTYHUY.png [4]: https://aur.archlinux.org/libxft-bgra.git signature.asc Description: PGP signature
Re: [dev] Regarding dwm and st logo being removed
On Thu, Apr 28, 2022 at 12:19:07PM +0200, Laslo Hunhold wrote: > On Thu, 28 Apr 2022 08:34:36 +0600 > NRK wrote: > > Dear NRK, > > > Recently noticed that the dwm and st logo was removed from their > > homepages[0][1]. > > > > I was wondering if there's any specific reason for that, or if there's > > plan for a new logo(s)? > > > > I atleast really liked the current logos, as they reflect the > > simiplicity of the software quite nicely :) > > > > [0]: https://dwm.suckless.org > > [1]: https://st.suckless.org > > I made the logos a few years ago and Hiltjo removed them recently. I > also liked them very much and would like to see them included again, but > respect that it's his discretion to remove them as he is the maintainer. > > What do the others think? > > With best regards > > Laslo > Hi Laslo, Sure I don't mind you added them back. With the inverted colors they are visible here. -- Kind regards, Hiltjo
Re: [dev] Regarding dwm and st logo being removed
Quoting Страхиња Радић (2022-04-28 05:28:29) > On 22/04/28 12:19, Laslo Hunhold wrote: > > What do the others think? > > I also like them, I think they contribute to overall visual identity of > suckless programs and suckless.org and should be reincorporated into the > website. I think the logos are a simple but characteristic 'trademark'. Maybe just a suckless logo would be sufficient.
Re: [dev][st] Solution: UTF-8 needs IBus!
Quoting Страхиња Радић (2022-04-28 01:43:26) > On 22/04/26 03:59, Robert Winkler wrote: > > To make a long story short: The input of UTF-8 characters with st needs > > an IBus daemon > > No, it doesn't. Well, I had the same problem on 3 computers running dwm/st. On a 4th, the UTF-8 input (é,ñ,ü,€,ß) worked out of the box, as well on another computer using st on GNOME. The later fact lead me to the conclusion, that GNOME is doing something different with the input. Indeed, GNOME by default is using ibus. For all of them - 'debianish' x64 and arm64 OSs: Pop OS!, Debian 11 Bullseye, armbian and dietpi - the direct input worked after installing ibus and im-config, and defining ibus as the default input. I programmed the keyboards, which pass the linux-codes, with QMK. Since I have little knowledge about the internals of st, I will not argue. Maybe im-config does the job? However, ibus/im-config solved my problem and maybe for others as well. Maybe ibus only is relevant for custom built QMK keyboards, but fair enough ;-). Best regards, Robert
Re: [dev] Regarding dwm and st logo being removed
On Thu, Apr 28, 2022 at 01:06:05PM +0200, Laslo Hunhold wrote:
> #main img[src$=svg] {
> filter: invert(1);
> }
>
> All within #main that are svg's are inverted in dark mode.
> Granted it makes use of a filter, which is not supported everywhere,
> but given prefers-color-scheme is also only supported by modern
> browsers, this should not be an issue.
>
> I hope everyone's okay with this.
The change (visually) looks fine to me and I'm happy to see the logos
back again =)
And while we're on the topic of dark mode; the current theme uses a #000
black for it's background. Which looks great my phone with AMOLED
display, but not so great on my desktop with an LCD panel where
something like #171717 looks much better.
I'm not asking to change it though, since that'll just swap the problem.
Just putting the info out there as feedback.
- NRK
Re: [dev] Regarding dwm and st logo being removed
On Thu, 28 Apr 2022 09:38:09 +0200
Страхиња Радић wrote:
Dear Страхиња,
> This can be remedied with CSS which applies white background to logos
> (perhaps with some padding: to also give a bit of a
> border).
>
> In my opinion, dark mode is unnecessary and favored by mainstream
> "webdevs".
I personally also like dark mode, but understand it's a matter of taste
(and 1 bit of information added to the online-fingerprint).
However, I managed to tweak it such that it now works with dark mode as
well by adding the following CSS-rule to the dark mode section in the
CSS:
#main img[src$=svg] {
filter: invert(1);
}
All within #main that are svg's are inverted in dark mode.
Granted it makes use of a filter, which is not supported everywhere,
but given prefers-color-scheme is also only supported by modern
browsers, this should not be an issue.
I hope everyone's okay with this.
With best regards
Laslo
Re: [dev] Regarding dwm and st logo being removed
On 28.04.22 12:19, Laslo Hunhold wrote: On Thu, 28 Apr 2022 08:34:36 +0600 NRK wrote: Dear NRK, Recently noticed that the dwm and st logo was removed from their homepages[0][1]. I was wondering if there's any specific reason for that, or if there's plan for a new logo(s)? I atleast really liked the current logos, as they reflect the simiplicity of the software quite nicely :) [0]: https://dwm.suckless.org [1]: https://st.suckless.org I made the logos a few years ago and Hiltjo removed them recently. I also liked them very much and would like to see them included again, but respect that it's his discretion to remove them as he is the maintainer. What do the others think? With best regards Laslo Hey guys, Just my two cents - I liked the logos and never use dark mode. Regards, Yan OpenPGP_signature Description: OpenPGP digital signature
Re: [dev] Regarding dwm and st logo being removed
On 22/04/28 12:19, Laslo Hunhold wrote: > What do the others think? I also like them, I think they contribute to overall visual identity of suckless programs and suckless.org and should be reincorporated into the website. signature.asc Description: PGP signature
Re: [dev] Regarding dwm and st logo being removed
On Thu, 28 Apr 2022 13:53:54 +0600 NRK wrote: Dear NRK, > Ah, that makes sense. But wouldn't it make sense to remove the logos > from *all* are projects then? > > Also since the logos are just svgs, I *think* it should be possible to > override the color of the "fill" dynmaically via css (?) If so, then I > think that's probably a better course of action :) sorry, I didn't see the thread was already responded to. It is possible to "externally" influence svgs to "switch" with css. I'll look into it. With best regards Laslo
Re: [dev] Regarding dwm and st logo being removed
On Thu, 28 Apr 2022 08:34:36 +0600 NRK wrote: Dear NRK, > Recently noticed that the dwm and st logo was removed from their > homepages[0][1]. > > I was wondering if there's any specific reason for that, or if there's > plan for a new logo(s)? > > I atleast really liked the current logos, as they reflect the > simiplicity of the software quite nicely :) > > [0]: https://dwm.suckless.org > [1]: https://st.suckless.org I made the logos a few years ago and Hiltjo removed them recently. I also liked them very much and would like to see them included again, but respect that it's his discretion to remove them as he is the maintainer. What do the others think? With best regards Laslo
Re: [dev] Regarding dwm and st logo being removed
On Thu, Apr 28, 2022 at 09:29:43AM +0200, Hiltjo Posthuma wrote: > Recently dark mode CSS support was added to the site. > > It was reported on IRC the logo's were not visible with them. Ah, that makes sense. But wouldn't it make sense to remove the logos from *all* are projects then? Also since the logos are just svgs, I *think* it should be possible to override the color of the "fill" dynmaically via css (?) If so, then I think that's probably a better course of action :) - NRK
Re: [dev] Regarding dwm and st logo being removed
On 22/04/28 09:29, Hiltjo Posthuma wrote: > Recently dark mode CSS support was added to the site. > > It was reported on IRC the logo's were not visible with them. This can be remedied with CSS which applies white background to logos (perhaps with some padding: to also give a bit of a border). In my opinion, dark mode is unnecessary and favored by mainstream "webdevs". signature.asc Description: PGP signature
Re: [dev][st] Solution: UTF-8 needs IBus!
On Tue, Apr 26, 2022 at 05:38:51PM -0500, Robert Winkler wrote: > 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 > Hi Robert, I think you meant to say your specific Input Method Editor (IME) requires ibus. Good to know your configuration problem is fixed now, -- Kind regards, Hiltjo
Re: [dev] Regarding dwm and st logo being removed
On Thu, Apr 28, 2022 at 08:34:36AM +0600, NRK wrote: > Hi, > > Recently noticed that the dwm and st logo was removed from their > homepages[0][1]. > > I was wondering if there's any specific reason for that, or if there's > plan for a new logo(s)? > > I atleast really liked the current logos, as they reflect the > simiplicity of the software quite nicely :) > > [0]: https://dwm.suckless.org > [1]: https://st.suckless.org > > - NRK > Hi NRK, Recently dark mode CSS support was added to the site. It was reported on IRC the logo's were not visible with them. I think these logos are a bit pointless, they just look like text, but less clear. -- Kind regards, Hiltjo
Re: [dev][st] Solution: UTF-8 needs IBus!
On 22/04/26 03:59, Robert Winkler wrote: > To make a long story short: The input of UTF-8 characters with st needs > an IBus daemon No, it doesn't. signature.asc Description: PGP signature
