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

We rewrote the Ghostty GTK application

mitchellh.com

Post reply on HN
Print view View original

31–40 of 228 posts

Re: We rewrote the Ghostty GTK application

#31

Post by AndyKelley »

mitchellh wrote: post #11
Lerc wrote: post #6

> Whatever your feelings are about OOP and memory management, the reality is that if you choose GTK, you're forced into interfacing in some way with the GObject type system. You can't avoid it. In the past this has also been my assessment of GTK. It lead me to decide to take the other path, to never directly use GTK. I appreciate the value in having a unified user interface between applications, but I have always tho…

> That lead me to think that GTK and the GObject system is opinionated in a way that are not terribly compatible with my own opinions. This might be amusing for me to say but... I also feel this way. I disagree a lot with the Gnome ecosystem's point of view. Funny! Using GTK for Linux was a pragmatic choice. A goal of Ghostty is to be "platform-native" (defined here because there's no such thing on Linux: https://gho…

Oh, I would love it if Wayland provided a standard UI toolkit (server-side)! Is that a thing that happened when I wasn't looking?

Re: We rewrote the Ghostty GTK application

#32

Post by jcastro »

LambdaComplex wrote: post #29
mitchellh wrote: post #11

Earlier quoted context omitted.

> That lead me to think that GTK and the GObject system is opinionated in a way that are not terribly compatible with my own opinions. This might be amusing for me to say but... I also feel this way. I disagree a lot with the Gnome ecosystem's point of view. Funny! Using GTK for Linux was a pragmatic choice. A goal of Ghostty is to be "platform-native" (defined here because there's no such thing on Linux: https://gho…

I like Linux because it gives me the freedom to make my system behave how I want. The GNOME devs seem to think that GNOME should only behave how they want. For example, last time I checked, GNOME required a third-party plugin just to move the clock from the center of the status bar to the side. I'm not at all surprised to see that this mindset extends to GTK.

> just to move the clock from the center of the status bar to the side.

And I like linux because there are plenty of people who also do not care about this and want to just use their computer.

Re: We rewrote the Ghostty GTK application

#33

Post by WD-42 »

mitchellh wrote: post #24
WD-42 wrote: post #13

Very nice writeup! I was actually just wondering what was going on with Ghostty, I've been daily driving it since initial release but I haven't noticed any updates since then (not that anything is particularly lacking, it's a great terminal!) Good to hear the Mitchell and the team are still hacking away at it! Thanks for the great software!

Hold onto your butts cause 1.2 is weeks away and the release notes if printed would cause a [larger than we already have] deforestation problem.

Looking forward to it!

Re: We rewrote the Ghostty GTK application

#35

Post by ripley12 »

> This has already led to more easily introducing GUI features like a new GTK titlebar tabs option

Yes! This is huge, I previously gave up on Ghostty because the title bar wasted so much space on my laptop screen: https://bsky.app/profile/reillywood.bsky.social/post/3lebapf...

I found the PR in case anyone else is curious what the new functionality looks like: https://github.com/ghostty-org/ghostty/pull/8166

Re: We rewrote the Ghostty GTK application

#36

Post by wofo »

schmichael wrote: post #17
WD-42 wrote: post #14

Earlier quoted context omitted.

I think one of the main points of the article was about how shockingly few memory issues they have encountered. He talks about how great of a fit zig + valgrind is.

Indeed, but I'm curious about the second class of memory correctness issue he mentions: > 2. All other memory issues revolved around C API boundaries. Is this something Rust, or any other language, has the ability to prevent any more than any other language? Or once you introduce a C API boundary is it back to tools like Valgrind?

Having worked on a few Rust projects that interface with C libraries, I think your last question is a good summary: once you introduce a C API boundary it's back to tools like Valgrind.

Maybe you could even say Zig is at an advantage there, because tools like Valgrind are considered part of the game, whereas in Rust they are way less commonly used (pure-Rust codebases don't need anything of the sort, unless you are using `unsafe`).

Re: We rewrote the Ghostty GTK application

#37

Post by akulbe »

do_not_redeem wrote: post #5
corsica wrote: post #2

I don't get the hype around this application. The only UI Ghostty has is tabs and the context menu, is it really worth the integration pain and now this rewrite? Maybe they're planning for more, like those GUI configuration dialogs that iterm2 has? Kitty uses OpenGL for everything and draws its own tabs, they're fully customizable and can be made to look however you want. By not wasting time on integrating with massi…

Well... a terminal is a GUI app, so they had to choose some GUI framework. On Linux GTK is as good a choice as any. (Yes I know you can skip the framework and talk to X11/Wayland directly, like xterm/foot do, but that's a pain all of its own.)

What about Qt? Would that have been a better experience? Or would you experience different issues?

Re: We rewrote the Ghostty GTK application

#38

Post by cosmic_cheese »

Lerc wrote: post #6

> Whatever your feelings are about OOP and memory management, the reality is that if you choose GTK, you're forced into interfacing in some way with the GObject type system. You can't avoid it. In the past this has also been my assessment of GTK. It lead me to decide to take the other path, to never directly use GTK. I appreciate the value in having a unified user interface between applications, but I have always tho…

In my view the primary reason for GTK’s prominence on Linux rides on one thing primarily: it’s got C bindings, and thus it has decent bindings for just about every other language under the sun too. If you’re not trying for anything fancy, these bindings can even be auto-generated.

The runner up Qt is much more tightly tied to C++ and Python to its detriment. You really need to meet devs where they’re at instead of insisting that they adopt a particular language to use your UI toolkit.

Aside from that, at the end of the day, if you’re building a full fat complex desktop app an old style imperative UI toolkit is probably one of the more practical choices you can make. They have an exhaustive set of battle tested, accessible widgets built in and their pitfalls are well known. Newer approaches expect you to write or import everything and start requiring increased contortions from the developer past a certain point of complexity.

Re: We rewrote the Ghostty GTK application

#39

Post by sbt567 »

schmichael wrote: post #17
WD-42 wrote: post #14

Earlier quoted context omitted.

I think one of the main points of the article was about how shockingly few memory issues they have encountered. He talks about how great of a fit zig + valgrind is.

Indeed, but I'm curious about the second class of memory correctness issue he mentions: > 2. All other memory issues revolved around C API boundaries. Is this something Rust, or any other language, has the ability to prevent any more than any other language? Or once you introduce a C API boundary is it back to tools like Valgrind?

I vaguely remember that there is a new language that promises "Safety across FFI boundary", but can't recall the name

Re: We rewrote the Ghostty GTK application

#40

Post by king_geedorah »

AndyKelley wrote: post #31
mitchellh wrote: post #11

Earlier quoted context omitted.

> That lead me to think that GTK and the GObject system is opinionated in a way that are not terribly compatible with my own opinions. This might be amusing for me to say but... I also feel this way. I disagree a lot with the Gnome ecosystem's point of view. Funny! Using GTK for Linux was a pragmatic choice. A goal of Ghostty is to be "platform-native" (defined here because there's no such thing on Linux: https://gho…

Oh, I would love it if Wayland provided a standard UI toolkit (server-side)! Is that a thing that happened when I wasn't looking?

No, there are no protocols intended to implement such a thing at this time. I'm not aware of anybody attempting to spec out such a protocol either, but I do think it's a really interesting idea.

Edit: s/protocol/interface

Post reply on HN