Alacritty is very slow on startup, I use a tiling manager and spawn new terminals frequently so this is very noticeable. I use st which is super fast and has everything I need available through patches
> Alacritty is very slow on startup Can you quantify that? Are you talking multiple countable seconds to open? It seems to open instantly for me but I can't tell if your talking about 0.5s or 5s being slow.
It's slow when relying on opening to be instantaneous so 0.5s feels very slow. I need it to be around 0.05s.
Thanks for calling this out. This is not something I would have thought to check myself. It's unfortunate the most common use of the word toxic is in a very abstract sense, but the behavior you identify is just plain unnecessary rudeness and a much more suitable use of the word. Can we assume people are acting in good faith until we have reason to think otherwise? As highlighted by the green-is-yellow issue, it is OK…
> But you can configure it yourself by ... The two first comments of the maintainer in the thread mentioned the configurability of alacritty, giving soft hints that maybe the user should just set it privately to comfort their private taste. I feel that discussions about taste choices can sometimes be the most tiring ones, because often people have different tastes and you can't give rational arguments why you like on…
In this case, it’s not even taste preference but color perception, which is even harder to objectify.
To be fair, I thought the dev’s response was adequate here. Just posting on the issue section that the “colors are wrong” while comparing with uxrvt, without any explanation or self-investigation as to why this could be a problem, has ample potential to be regarded as rude to the devs (I’m using this another terminal app and have better colors, why aren’t you fixing this?) And please note that Mac OS is NOTORIOUS for…
Adequate, meaning good enough, but with room for improvement?
Yeah, obviously not “perfect”, but totally understandable if the dev’s stressed out a bit.
> To be fair, I thought the dev’s response was adequate here No it wasn't. It was bad. Granted, the original bug report could have been a bit clearer, but the reporter was more than happy to help out and promptly responded to the questions and even some checking of the RGB of the colour in question, and then offered to open up a new related issue. But the dev in this case took the worse interpretation of the reporter…
And from the dev's followup explanation it just feels like their default is that everyone is entitled so they react accordingly. That response sure came out of left field, and I think the dev is lacking a little self awareness. Taking a defensive stance from the beginning is just bound to cause unnecessary drama.
No, I'm just an app developer who used GTK recently and noticed that a lot of what people say about it is based on out-of-date information. My experience really wasn't that bad, progress is being made and issues are being addressed, even though it's not happening as fast as some would like. For whatever reason there is a staggering amount of misinformation in these HN threads.
Based on my personal interactions with GNOME developers and unresolved bugs, I suspect your experience is the exception, not the broad norm.
I don't meant to say it doesn't have bugs, of course it does. Every project has bugs. As with all open source, submitting patches to fix those bugs will usually go farther than patiently waiting and hoping that another volunteer will get frustrated enough by the bug to fix it eventually. The obvious segfault bugs that affect everyone badly will tend to get fixed pretty fast, the more obscure ones that arise from weird use of widgets (and need a lot of in-depth debugging) are a harder thing to ask a volunteer to spend their time on.
No, I'm just an app developer who used GTK recently and noticed that a lot of what people say about it is based on out-of-date information. My experience really wasn't that bad, progress is being made and issues are being addressed, even though it's not happening as fast as some would like. For whatever reason there is a staggering amount of misinformation in these HN threads.
Agreed with the sibling comment. My own experience with GTK and their developers have been awful.
> GTK and most of the GNOME project are much of the same. Avoid them and don't make the mistake of thinking their libraries are meant for others to use. Choose your dependencies wisely. Sometimes only a crystal ball would have helped but often, a little bit of due dilligence would have prevented lots of upgrade pain down the line.
I dug in and read the linked thread and patch, and this may be a bit in the weeds, but nobody on the linked thread called out Christian Persch's comment [1] which doesn't make much sense to me. To be completely fair, this is a comment from 2015, 12 comments deep in an otherwise relatively isolated bugzilla forum, so maybe we shouldn't judge too harshly. Anyways, have a look: > In reply to Daniel Micay from comment #1…
>What exactly stops gnome terminal (the obvious referent of "all the other terminals") from implementing this itself once the apis are available?
They could but then every terminal would have to re-implement the same feature causing needless code duplication. You can see here later a comment from the tilix developer that explains it: https://github.com/gnunn1/tilix/issues/848#issuecomment-2892...
> GTK and most of the GNOME project are much of the same. Avoid them and don't make the mistake of thinking their libraries are meant for others to use. Choose your dependencies wisely. Sometimes only a crystal ball would have helped but often, a little bit of due dilligence would have prevented lots of upgrade pain down the line.
I was also disappointed by the recent removal of static linking support in GTK [1]. It worked for a long time and now was made impossible. The reason given was "don't want to support it". That would make sense if it was a maintenance-intensive topic, here the only thing required is to use Meson's default options. I don't really buy the argument of "preventing to use internal APIs"; no FOSS developer in their right mi…
Why can't you static link against that libgtk_static target that already exists? That should be accessible if you have gtk as a meson subproject. It doesn't actually look like anything special needs to be done here.... I'll be commenting on that issue.
No, I'm just an app developer who used GTK recently and noticed that a lot of what people say about it is based on out-of-date information. My experience really wasn't that bad, progress is being made and issues are being addressed, even though it's not happening as fast as some would like. For whatever reason there is a staggering amount of misinformation in these HN threads.
Agreed with the sibling comment. My own experience with GTK and their developers have been awful.
I'm sorry to hear that. I'll reiterate that if someone was rude and hostile to you, that would probably be considered a code of conduct violation, and it would be appreciated if that was reported so it doesn't happen again.