That is my impression as well.

Just for completeness: According to GNOME Human Interface Guidelines app icons are full-color icons: https://developer.gnome.org/hig/guidelines/ui-icons.html My app should be fine! 😊

Haven’t seen it indeed. Afaik, app icons should be fine. In case they are not, I have an idea, what the issue might be. Thank you.

Reading through the bug tracker, the GNOME approach seems to be one I see way to often: “The standard is outdated in our view and does not suit us. Let’s just treat it as obsolete and make our own incompatible thing. If this breaks stuff, its not our problem.” I prefer those that say: “We need an updated standard.” But they seem to be the minority, at least these days.

Still working on my app launcher. Currently working on on user config. Recently I added support for app icons and there freedesktop.org icon themes. Icon themes are more complicated than I expected. Themes can have multiple fallbacks themes which themselves can have multiple fallback themes. Totally makes sense. I just did not think about it too much before implementing it. Allowed me to implement a nice breadth-first search. Most themes have a single fallback theme, so it is not of much use, but hey, I follow the spec. 😅

“Asynchronous programming in Rust” is really good, imho. My colleagues and I read it to get a deeper understanding of async Rust. I was skeptical at first, because it is from Packt, but it turned out to be a decent book. Also enjoyed the recent rustacean station episode with its author.

At work and for hobby projects. At work I am looking at using Rust for safety-critical systems. As a hobby I am building a dmenu alternative. It is a fun project and I have a menu that satisfied my wishlist.

I would not call it a bash. Go’s approach naturally comes up in discussions on async Rust. Thus, it makes sense to at least briefly mentioning the trade-offs that approach has.

Yeah, I am always happy if a project not only mentions where it shines but also where it does not. But it is common practice not to do so. Same in academic publishing. Everybody is focused on selling oneself, it seems.

Maybe ‘failing’ is too strong. What I mean is that in situations like the one I showed, texture healing cannot solve the problem of uneven texture. Not that they claimed it does. It just eases the problem. I like to know the trade-offs. When does it provide an improvement and when not? What tensions does that create?

From a users point of view, I do not know if it ‘fails’ or not. I totally agree with you. Maybe the I would find to distinct ‘m’ glyphs annoying, maybe not. And example emphasizes the ‘problem’. Maybe, I woukd even notice while coding or writing. To know that, I need to try. I just like to know the trade-offs in advance.

Interesting. Thanks for sharing. I started with WYSIWYG and did not like editing with proportional fonts. Things do not align, the cursor jumps around and movements have variable distances. But I much prefer looking at beautifully typesetted proportional font (e.g. with LaTeX). While I think, monospaced font are nice for editing, they are okayish to look at.

Thanks for the link. I will look into it and maybe try proportional for coding once more. Another idea I really like are almost proportional fonts. Read about these fonts a few month ago. So far I haven’t tried them.

Technically, font healing is a neat idea. It fails for text that does not meat its requirements, i.e. two ‘m’ next to each other. Depending on the characters around them, this might create two different ‘m’.

This is unavoidable, of course. The only solution are proportional fonts. So font healing is a nice idea. It creates a more consistent spacing at the price of less consistent glyphs. Whether one likes this compromise, is a matter of taste. I personally lean towards consistent glyphs, but I did not try it for an extended period.

I am working on an alternative to dmenu. My goal for it is to be fully configurable via a toml file. Most importantly it shall be able to toggle between types of entries (desktop entries, /usr/bin) on the fly. As of now, it is a less mature version of j4-dmenu-desktop and progress is slow. But it works as my daily driver on i3wn, both on my work VM and my personal laptop. So I can live with slow progress.

I prefer to keep tooling for that at a minimum. Therefore I use git only. My approach is taken from here: https://www.atlassian.com/git/tutorials/dotfiles The only difference: My git alias is dotfiles not config. I find that to be less confusing. Additionally, I source system-specific configs, where appropriate. These are not stored in dotfiles. There is a small todo section in my readme.