#Xresources

Patrick :neocat_flag_bi:patrick@hatoya.cafe
2025-11-07

One Open-source Project Daily

Over 425 terminal color schemes/themes for iTerm/iTerm2. Includes ports to Terminal, Konsole, PuTTY, Xresources, XRDB, Remmina, Termite, XFCE, Tilda, FreeBSD VT, Terminator, Kitty, MobaXterm, LXTerminal, Microsoft's Windows Terminal, Visual Studio, Alacritty, Ghostty, and many more

https://github.com/mbadolato/iTerm2-Color-Schemes

#1ospd #opensource #colorscheme #freebsdvt #iterm #iterm2 #konsole #konsolecolorschemes #lxterminal #osxterminalthemes #putty #puttycolorschemes #schemes #terminal #terminalschemes #terminalthemes #terminator #theme #themes #windowsterminal #xrdb #xresources

Felix Palmen :freebsd: :c64:zirias@bsd.cafe
2024-07-29

@matuzalem just btw, you can persist all that stuff in your #XResources. Add there

Xmoji*glitches: 1
Xmoji*emojiFont: emoji-24

and make sure to qualify your existing *background (e.g. as XTerm*background), or, override it for xmoji with

Xmoji*background: #bebebe

Felix Palmen :freebsd: :c64:zirias@bsd.cafe
2024-07-29

@matuzalem BTW having another closer look at the screenshot, it looks like just the "default background" color is wrong. Are you absolutely sure you don't have any #Xresources set? Could you please verify like that:

xrdb -query | grep -v background

Felix Palmen :freebsd: :c64:zirias@bsd.cafe
2024-07-19

General thoughts about configuration of "modern" X11 desktop apps:

Next step for my #Xmoji #X11 #emoji #keyboard will be adding runtime configuration. Sending fake key-press events has some parameters (how long to wait before restoring the keymap, which hacks/workarounds to enable for sending the events ...) that should be configurable at runtime. A history of recently used emojis should be available and persisted. There may be more things to add here later (allow multiple instances? show and use a "tray icon"?).

I already have configurations for rendering and appearance aspects. For these, I use classic #Xresources. Even if they aren't that popular any more nowadays, they're IMHO the perfect place for such things: The configuration is tied to the currently running X server. They also offer a fine-grained scheme to match settings to classes and instances (e.g. individual widgets). So, learn about them and enjoy! 😄

Runtime configuration is a different beast. Back in the days, you had these dialogs with the typical three buttons, "apply" made changes effective without persisting them, "ok" persisted them and "cancel" reverted anything not persisted yet. There was also often some action available to re-load the currently persisted configuration.

Well, not any more. Nowadays, the predominant user experience is applying and persisting any change instantly. This is nice, but it creates an interesting issue, which most applications choose to just ignore. If either multiple instances of the same app are allowed to run for the same user on the same host, or the configuration is stored on some network share used by multiple hosts, inconsistencies are easily possible, with multiple instances of the app having a different idea about the "current" configuration and just persisting that on any change, overwriting what a different instance might have changed.

I came to the conclusion that I shouldn't ignore that issue for Xmoji. At least for persisting the emoji history, it would be unacceptable.

So, the obvious solution is that the configuration file must be monitored, so that any "remote" change can also be applied immediately in every running instance. The naive and portable solution for monitoring is to periodically stat() the file to check the modification timestamp. On network filesystems, that's the only thing that will work. I'll probably start with implementing just that.

For local files, there are platform-specific ways to obtain notifications from the OS (or kernel), which is better (immediate notification) and more efficient. #Linux has #inotify, #FreeBSD has #kqueue. I'm currently exploring docs and doing a few pocs for these interfaces as well ... this might really take a while, let's see. 🙈

Please comment with your thoughts about that if you have any! 😉

Felix Palmen :freebsd: :c64:zirias@bsd.cafe
2024-07-10

Forgot to document the #XResources before release. 🙈 Done now!

github.com/Zirias/xmoji
#X11 #emoji #keyboard

Felix Palmen :freebsd: :c64:zirias@bsd.cafe
2024-06-20

#X11 #programming with #xcb, step by step: #tooltips are "done" 😉 (including styling from #XResources).

Hm, what's next ... A tab widget? A menu? "dialog" windows? Will need all of this 🙈

Felix Palmen :freebsd: :c64:zirias@bsd.cafe
2024-06-15

@morgant I see it's even more important for testing a window manager 😉

But even for a "normal" client, it's a nice way to test with separate #Xresources, different window managers and configurations etc without fiddling with your main X session config 👍

Felix Palmen :freebsd: :c64:zirias@bsd.cafe
2024-06-13

I got sidetracked working on #XResources support ... it all started from the wish that a child #widget should used its container's font when it doesn't have its own font configured (will be helpful e.g. for tooltips...)

Now I also integrated command-line overrides for resources in my XRdb resource database implementation, which is very cool. Actually, this system slightly reminds of CSS ... I can configure the looks of my #X11 application very flexibly!

Last thing I added was support for more formats to specify colors, plus querying the X server for named colors 😎.

#TIL: #XLib has some "color management" code and can parse and convert color specifications in different color spaces. ðŸĪŊ Ok, I don't want to link XLib (only #xcb), and I won't implement *this* myself, #RGB and #RGBA (together with "well-known" X11 color names) should really be all you ever need ðŸĪŠ

github.com/Zirias/xmoji/blob/e

Felix Palmen :freebsd: :c64:zirias@bsd.cafe
2024-06-08

@jhx Testing my current state in #Xephyr, without any #Xresources loaded, running #fvwm3 with no configuration ....

I guess my "ColorSet" class needs a few more values. Only one flavor of "background color" for the default state (not selected/inactive/hovered) doesn't cut it, e.g. a #TextBox should always stick out ... ðŸĪ”

#X11 #xcb #programming

Felix Palmen :freebsd: :c64:zirias@bsd.cafe
2024-06-06

Added color configuration via #XResources, using Widget names and class names â€Ķ this is pretty nice, a shame so few applications nowadays use this!

github.com/Zirias/xmoji/commit

Found and fixed a few bugs on the way as well â€Ķ 😅

#X11 #xcb #programming

Felix Palmen :freebsd: :c64:zirias@bsd.cafe
2024-06-06

A commandline flag to enable a workaround really isn't suitable ... so it was time to finally support #XResources. I wasn't happy with the xcb utility lib I found, so I did it from scratch 🙈
github.com/Zirias/xmoji/commit
#X11 #xcb #programming

nebunez :manjaro: :emacs:nebunez@fosstodon.org
2020-04-01

If anyone can help me figure out why this hot pink is in my terminal and how to get rid of it I will give you much respect.

#terminal #colors #xresources #askmastodon #askthefediverse

A screenshot of a terminal showing colors and their corresponding terminal color codes. Hot pink is showing up over and over when it shouldn't be.
Clematis :openbsd:clematis@framapiaf.org
2018-09-24

Finally found the right font size for me: 13 on a 24" 2k monitor or 15 on a 12" 2k monitor.
URxvt.font: xft: Courier New:style=Medium:size=15
#urxvt #terminal #font #sizematters #Xresources

Client Info

Server: https://mastodon.social
Version: 2025.07
Repository: https://github.com/cyevgeniy/lmst