Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Use Alacritty instead of Termite

github.com

Post reply on HN
Print view View original

321–330 of 331 posts

Re: Use Alacritty instead of Termite

#321

Post by zxzax »

jeroenhd wrote: post #309
zxzax wrote: post #226

Earlier quoted context omitted.

>GTK4 still doesn't support native rendering of window controls FYI this is not entirely correct. There is a flag for this in GDK4: https://developer.gnome.org/gdk4/4.0/GdkToplevel.html#gdk-to... It may be that this is not implemented yet for some backends (I think it is not implemented in the Windows one) but they probably would accept a patch to implement it there if you know how to do it. Please avoid making these…

Allowing for SSR is a good step, but does this also render the other controls in their native style? The window border is one important place for styling, and I'm glad GTK4 will improve the situation once it hits the mainstream distros, but as far as I can tell, the rest of the controls (buttons, textboxes, etc.) are still rendered by the application rather than by the system. I've given GTK4 a try on Windows, and al…

I'm sorry, I misunderstood. I thought you meant the toplevel window controls like close, minimize, maximize. There is currently no way to make all the widgets render using the Win32 API to look like Windows widgets. You probably don't want to do that anyway, it will start to look and act really inconsistent when an application uses custom widgets.

Somebody could definitely fake a theme that makes the widgets look like Windows, and ship that with their windows builds, if that was desired. That to me is a much more viable option. There are multiple themes like this for GTK3. [0] [1] I don't know if any have been ported to GTK4 yet, but they could.

[0] https://github.com/B00merang-Project/Windows-10 [1] https://github.com/B00merang-Project/Windows-7

Re: Use Alacritty instead of Termite

#322

Post by zxzax »

infogulch wrote: post #313
zxzax wrote: post #298

Earlier quoted context omitted.

>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 de…

I don't have any particular opinion on the best way to do this, but from those comments by the tilix developer, it doesn't seem like the approach taken by vte-ng was the right one either.

From the VTE maintainer's perspective, adding any additional external symbols can create trouble, because those symbols have to be maintained for the duration of the major version, and they can prevent further refactorings. It's usually not easy to get public API changes into old libraries like this.

Re: Use Alacritty instead of Termite

#323

Post by zxzax »

nh2 wrote: post #316
zxzax wrote: post #306

Earlier quoted context omitted.

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…

For Go, Rust, Haskell, autoconf, CMake, you would invoke the meson and ninja commands as part of your build process. You can't use them in the same exact way as meson subprojects, but these are just shell commands. It's the standard way to build any project with an external build tool. Am I misunderstanding a requirement? For a static build deployed in a specialized situation, you would likely need a customized gtk build to begin with.

I think it would be worth asking if they could keep that libgtk_static around, for users who know what they are doing. Make it very obvious you are not creating extra burden on them for just your use case. The problem with an option to build and install is that it makes it so they have to support static linking in lots of other use cases, which it doesn't seem they want to do.

I'd be interested to hear if static linking GTK even has that many benefits. From what I have seen, the library may not play so well with LTO.

Re: Use Alacritty instead of Termite

#324

Post by infogulch »

zxzax wrote: post #322
infogulch wrote: post #313

Earlier quoted context omitted.

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 de…

I don't have any particular opinion on the best way to do this, but from those comments by the tilix developer, it doesn't seem like the approach taken by vte-ng was the right one either. From the VTE maintainer's perspective, adding any additional external symbols can create trouble, because those symbols have to be maintained for the duration of the major version, and they can prevent further refactorings. It's usu…

These things are certainly reasonable to consider. Thanks for adding additional context.

Re: Use Alacritty instead of Termite

#325

Post by oblio »

fuzxi wrote: post #245
shi_tty wrote: post #20

Earlier quoted context omitted.

Lots of things alacritty cannot do- 1) If you scale certain fonts using fontconfig, alacritty would ignore that. 2) No emoji colors, no ligatures (and thus no flags), also emoji size has problems ... and not to mention it's one of the slowest (yes! contrary to what they blowhard they response time to keys is very large) terminals out there. List is endless, termite had its place, but there is no doubt that there is s…

What's the appeal of emoji in the terminal?

Well, a random example, I imagine that people want to:

cat randomfile

and see the output correctly, at least.

Re: Use Alacritty instead of Termite

#326

Post by bfrog »

apocolyps6 wrote: post #195

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"

The issue says the color choice was poor, effectively critiquing the ability of the person who chose that color.

I'd be insulted too. Wording choices matter.

Re: Use Alacritty instead of Termite

#327

Post by bfrog »

est31 wrote: post #275
apocolyps6 wrote: post #195

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"

> Strike 2/2 was multiple devs responding to OSX issues with "switch operating systems" What are the devs supposed to do? Debug the proprietary driver? They might not even own a Mac device because they give the software away for free and don't want to spend thousands on their spare time hobby. OpenGL drivers, regardless of manufactuer btw, have massive issues with bugs. They were so serious in fact, that the original…

Why do people insist on supporting the closed source horror show of os x aid beyond me.

Apple docs are some of the worst on the planet. It's like they intend on making the barrier to entry high so once you are in the club you somehow have prestige.

No, you have Stockholm syndrome.

Re: Use Alacritty instead of Termite

#328

Post by dnr »

zxzax wrote: post #320
dnr wrote: post #318

Earlier quoted context omitted.

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 te…

You're right, condescension is the wrong word. I apologize.

I do think it's misplaced confidence, though. Look at the upvotes/downvotes on the comments in the type-ahead issue thread. What the gnome developers are saying is clearly unpopular, and what the person who filed the issue and others are saying is clearly popular. Yes, of course, that's not a representative sample of all users. But was there ever a representative sample taken? What gives them the confidence to declare that the search behavior is superior, and so far superior that it must completely subsume the old behavior without even an option? No evidence is presented in that thread. They only say "This was a decision made a while ago, because people believed that searching can provide the same functionality." On what evidence is that belief based on, and what would be sufficient to overturn it? How large of a user outcry would there need to be? If this were my software and 59 people thought that one of my decisions was wrong (the largest vote count in that thread), I would start to strongly question my assumptions. No such questioning appears to be happening here.

To respond to your specific replies:

> technical review

This is a design question, not a bug. It's not about the code. The complaint is obviously valid.

> I don't think it would be much benefit for there to be a setting

Of course, anyone who will keep a setting in one position doesn't see value in there being a setting. I don't either: I'd be even happier if it always worked the old way, instead of a setting. But that's what settings are for, where there's multiple valid ways for something to work and not everyone agrees.

> technically viable

The old behavior is obviously technically viable, it worked that way for many years. So again, that's irrelevant, unless you're arguing that a setting to switch the behavior is too technically difficult, which seems implausible.

> Once the decision has been firmly made, there's little purpose to accepting further feedback after that.

Of course there is! If you don't accept further feedback, how will you ever know if your decision was wrong? This is the crux of it: a decision was "firmly" made by some developer based on who-knows-what criteria, and then no feedback is accepted, no matter how loud.

> losing users

I'm not a gnome user and never will be, but I'm forced to accept these decisions because they affect the gtk file dialogs also, and I can't exactly quit every piece of software that uses gtk.

Re: Use Alacritty instead of Termite

#329

Post by nh2 »

zxzax wrote: post #323
nh2 wrote: post #316

Earlier quoted context omitted.

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…

For Go, Rust, Haskell, autoconf, CMake, you would invoke the meson and ninja commands as part of your build process. You can't use them in the same exact way as meson subprojects, but these are just shell commands. It's the standard way to build any project with an external build tool. Am I misunderstanding a requirement? For a static build deployed in a specialized situation, you would likely need a customized gtk b…

I think there's a misunderstanding: Most people want to use the .a file from their Linux/package distro that provides static libraries, such as Alpine Linux or nixpkgs.

Such package distributions just use the build system default options to build static libs. For example, Alpine might use `-Ddefault_library=both`.

> if they could keep that libgtk_static around

Why make these special cases instead of just using the build system defaults? That's easier to maintain and more obvious.

> I'd be interested to hear if static linking GTK even has that many benefits

One benefit is almost-infinite backwards compatibility that the Linux and Xorg ABIs provide, being able to make GUI apps that work out of the box everywhere.

Another is that these generated executables are very small, e.g. 12 MB for a full static GTK GUI app [1], or 6 MB when xz-compressed.

This is much less than when using shared libraries. One reason is that dead-code elimination works much better for static linking: It links in only the functions you actually use. For dynamic linking, it's always the entire .so.

[1] https://github.com/nh2/static-haskell-nix/releases/tag/c-sta...

Re: Use Alacritty instead of Termite

#330

Post by perjes »

apocolyps6 wrote: post #195

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"

Another example of the bad attitude of the core devs (there are many, just look through some of the closed issues): https://github.com/alacritty/alacritty/issues/5029

I wish Kitty had more hype going for it, it deserves it more IMO.

Post reply on HN