Live data from Hacker News

Use Alacritty instead of Termite

github.com

311–320 of 331 posts

Re: Use Alacritty instead of Termite

#311
post #276

Earlier quoted context omitted.

GTK4 still doesn't support native rendering of window controls, so unless you're willing to create a faux "native" theme, your application will look like it doesn't belong on anything other than a Gnome desktop. I think it's idiotic and childish that the devs stick to their guns like this when there's clearly a high demand for a crucial feature like this. I dislike the project as a developer. Don't get me wrong, I'm…

> GTK4 still doesn't support native rendering of window controls Sorry, this ship has sailed, and I find that bringing "native" into an argument simply invalidates the argument. That "native" has changed so much over the years shows that there isn't one "truth". The fact that things like Electron and Flutter and other toolkits exist clearly demonstrates that end users don't give one iota of damn whether a control is…

Users don't get a choice whether a control is native or not, that doesn't mean they don't have a preference.

There's a few code editors out there integrating heavily with macOS that get featured here on HN once a while, and every time the comments are filled with people complimenting how well it works with the operating system and how nicely it integrates.

People also complain all the time about how Google sticks to material design on iPhone, even though the rest of the device follows an entirely different standard. If users really didn't care about native controls, that wouldn't be a problem at all.

When an application fits into the system, it's generally celebrated, but we've reached the point where we stopped expecting any form of integration anymore because every application is Javascript wrapped into a copy of Chromium now, if you even get a desktop version of the application in the first place.

the fact that Electron and Flutter and React Native and others exist clearly demonstrates that developers don't give one iota of a damn whether a control is native or not. These are tools of developer comfort, not of user comfort. Users don't care what you use to build your applications, as long as your app does the things they want to do well.

I don't see anyone celebrating the diversity of ways the different X buttons on their desktop looks, but I do see people enjoying the native look. To me, that seems like proof that this is a feature people are missing but not vocalising rather than that people don't care about.

In the end, people enjoy native experiences more, but native experiences cost more time and effort to produce and therefore more money. Consumers want free or cheap apps so businesses use cross-platform toolkits to reduce cost and effort, but these platforms certainly don't prove that users don't give a damn. They prove that they value having an app for cheap over having a good app for more money.

Re: Use Alacritty instead of Termite

#312

I was considering switching to Alacritty earlier this week, but a quick look at some github issues changed my mind. The devs come off super toxic. Take a look at this guy that got verbal abuse for pointing out the color labeled "green" looks more like banana than lime: https://github.com/alacritty/alacritty/issues/1561 Strike 2/2 was multiple devs responding to OSX issues with "switch operating systems"

Yeah, this was my take away as well. Also, iirc their claims of Alacritty being the "fastest" are dubious at best. I used Kitty for a while instead, which is very similar. More recently I've been trying out Foot: https://codeberg.org/dnkl/foot

I must say I am very impressed by Kitty's number of open and closed issues on Github. And it has so many features. The developer also seems like a nice guy and open to suggestions. I have used urxvt for a long time but wanted to try something more modern out, and set Kitty up today with a nice small config. I like it a lot so far.

Re: Use Alacritty instead of Termite

#313
post #298

Earlier quoted context omitted.

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...

Yes that's the case Christian was making (implicitly).

Another case could be that (1) maybe there isn't only one right way to implement such a feature, and (2) pulling the implementation down into the component layer leaves no space for experimentation or choice between different potential implementations, and (3) given the enormous pain of making any modifications in the GTK component layer (as this issue clearly demonstrates) I can sympathize with a dev that uses the component in their app shying away from the prospect of running every single idea through such a painful interaction every time they want to experiment with something. One might argue that there's a better api somewhere between "exposing raw block selection functions" and "fully-baked selection feature" that covers most needs and still provides desired flexibility, but (4) you don't find such an ideal api by theorizing from first principles, you have to derive it from experience and nobody can get such experience unless the lower-level api is available in the first place.

Re: Use Alacritty instead of Termite

#314
post #312

Earlier quoted context omitted.

Yeah, this was my take away as well. Also, iirc their claims of Alacritty being the "fastest" are dubious at best. I used Kitty for a while instead, which is very similar. More recently I've been trying out Foot: https://codeberg.org/dnkl/foot

I must say I am very impressed by Kitty's number of open and closed issues on Github. And it has so many features. The developer also seems like a nice guy and open to suggestions. I have used urxvt for a long time but wanted to try something more modern out, and set Kitty up today with a nice small config. I like it a lot so far.

> The developer also seems like a nice guy and open to suggestions.

To be clear, we’re talking about Kovid here, right?

Re: Use Alacritty instead of Termite

#315
post #312

Earlier quoted context omitted.

I must say I am very impressed by Kitty's number of open and closed issues on Github. And it has so many features. The developer also seems like a nice guy and open to suggestions. I have used urxvt for a long time but wanted to try something more modern out, and set Kitty up today with a nice small config. I like it a lot so far.

> The developer also seems like a nice guy and open to suggestions. To be clear, we’re talking about Kovid here, right?

Yes.

Re: Use Alacritty instead of Termite

#316
post #306
post #302

Earlier quoted context omitted.

Projects in other programming languages for which Meson is not a choice also want to link statically (thus need the `.a` file installed).

Where is meson not a choice, when it's already needed to build gtk? Projects written in other languages would still probably want to have it as a subproject and then invoke meson as part of the build process to build gtk, you wouldn't need to rewrite your whole build process in meson. If this is wanted in a distro, that distro can install that .a file if they want to support it. I don't see why upstream support is ne…

Many programming languages do not use Meson as a build system (examples: Go, Rust, Haskell). Some C or C++ projects may use autoconf or CMake, in which case you cannot use Meson subprojects either.

Distros use `-Ddefault_library=both` or `=static`, and let Meson install the built archive files; this is what is broken in that issue. It is surprising that this flag does nothing for GTK when it works as expected for all other Meson projects.

You could copy the archive file behind the Meson install action's back, but the maintainers' point on the issue is: "GTK isn't meant to be built as a static library" and "why do you think you need a static build of GTK4?".

If they do not want to support it, there's no guarantee the .a file will still be there tomorrow. That's what "upstream support" means.

Re: Use Alacritty instead of Termite

#317

When stepping away from KDE to sway, tried diffrent terminal emulators, but especially compared konsole, termite & alacritty. Back then (October 2020) I found alacritty to have really slow startup times on high-end machines (and got confirmation that's it's not my fault on IRC). Even massive Konsole started up faster. It also treats Wayland badly. So I settled with Termite, which I really like so far. It's sad that i…

Drew DeVault just started recommending foot over Alacritty. You might want to check it out.

Re: Use Alacritty instead of Termite

#318
post #154

Earlier quoted context omitted.

As someone who has to occasionally work on a Gnome desktop, I can confirm that they still haven't fixed type ahead in Nautilus. Another point is that their Alt-Tab has a strange auto-grouping behaviour that totally breaks my workflow. (I have multiple terminal windows open and switching between them is a pain, it has to be seen to be believed). Two big annoyances, and reading that type-ahead thread quoted above is qu…

>it's been a long time I've felt such an enormous disgust at the amount of neglect and arrogance that is being displayed there. Please do not assume bad faith. Type-ahead has some confusing usability issues, such as that it only matches against the beginning of the filename, which from my reading is why it probably will not be brought back. The way forward is to help get the current solution up to par. I feel your pa…

I don't even use Gnome, but the behavior in the gtk open and save dialogs changed in the same way a few years ago, so I'm going to assume it's the same issue:

I hate hate hate the new search behavior, and would go back to the old ("type-ahead") behavior in a second if there was a setting I could toggle.

I don't think it's "bad faith", I think it's just weird group-think and having things other than the users as priorities. The amount of condescension and misplaced confidence displayed in that thread is impressive. If you (or anyone reading this) is affiliated with the Gnome project, please reconsider how you handle and incorporate user feedback into your products.

Re: Use Alacritty instead of Termite

#319
post #276

Earlier quoted context omitted.

> GTK4 still doesn't support native rendering of window controls Sorry, this ship has sailed, and I find that bringing "native" into an argument simply invalidates the argument. That "native" has changed so much over the years shows that there isn't one "truth". The fact that things like Electron and Flutter and other toolkits exist clearly demonstrates that end users don't give one iota of damn whether a control is…

Users don't get a choice whether a control is native or not, that doesn't mean they don't have a preference. There's a few code editors out there integrating heavily with macOS that get featured here on HN once a while, and every time the comments are filled with people complimenting how well it works with the operating system and how nicely it integrates. People also complain all the time about how Google sticks to…

> the fact that Electron and Flutter and React Native and others exist clearly demonstrates that developers don't give one iota of a damn whether a control is native or not.

Because devs rarely have the time to do their frontend work 3-5 times over and over for each different platform. Cross-platform is the best choice, especially if you want anything to be available outside of Windows or rarely macOS.

> but I do see people enjoying the native look

I don't. It reminds me of the good old days on Windows XP when you couldn't tell a program from another because they were all "native" and looked the same. I prefer an app to keep a cross-platform look - e.g. Google's stuff looks the same on the web and on mobile, so you aren't stuck rediscovering everything when you switch platforms.

Re: Use Alacritty instead of Termite

#320
post #318
post #154

Earlier quoted context omitted.

>it's been a long time I've felt such an enormous disgust at the amount of neglect and arrogance that is being displayed there. Please do not assume bad faith. Type-ahead has some confusing usability issues, such as that it only matches against the beginning of the filename, which from my reading is why it probably will not be brought back. The way forward is to help get the current solution up to par. I feel your pa…

I don't even use Gnome, but the behavior in the gtk open and save dialogs changed in the same way a few years ago, so I'm going to assume it's the same issue: I hate hate hate the new search behavior, and would go back to the old ("type-ahead") behavior in a second if there was a setting I could toggle. I don't think it's "bad faith", I think it's just weird group-think and having things other than the users as prior…

>The amount of condescension and misplaced confidence displayed in that thread is impressive.

I would say that assuming condescension is assuming bad faith. If there is a comment that is truly rude and dismissive, it should be reported as a code of conduct violation. Otherwise, please don't assume the response is trying to put you down because it's disagreeing on technical grounds. Any bug report has to go through technical review, and the developers will almost always have more information about the code than the reporter.

>I hate hate hate the new search behavior, and would go back to the old ("type-ahead") behavior in a second if there was a setting I could toggle.

To give another opinion, I personally don't feel the same way about this, and I don't think it would be much benefit for there to be a setting.

>If you (or anyone reading this) is affiliated with the Gnome project, please reconsider how you handle and incorporate user feedback into your products.

I'm not affiliated, I'm just expressing my personal opinion on this, as you are. Not all user feedback is created equal. Sometimes, the developer must firmly say no because something isn't technically viable. Users don't decide what is technically viable or not, only the developer tasked with writing the code can make that decision. Sometimes, the developer is faced with a choice between competing requirements, and it's not possible to fulfill both technically. Once the decision has been firmly made, there's little purpose to accepting further feedback after that. Committing to a solution means the developer has to accept the effects of it, losing users is always a possible effect, but so is users changing their mind.

Post reply on HN