We rewrote the Ghostty GTK application

https://mitchellh.com/writing/ghostty-gtk-rewrite

by tosh • 11 months ago

428 224 11 months ago

corsica• 11 months ago

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 massive frameworks for drawing tabs, Kovid was able to quickly implement really useful things that Ghostty is sorely missing, like wrapping the output of the last command in a pager (run 'ps -auxf' and press Ctrl+Shift+G — this thing so useful it's hard to go without it now. It also works for remote shells across SSH sessions.)

hyperbolablabla• 11 months ago

Agreed, seems like a lot of unnecessary girating just to implement something that would've been much simpler + cross-platform with a custom UI toolkit and something like opengl. Tabs are like UI 101

ChocolateGod2• 11 months ago

Easier integration with the desktops accessibility and input stack? When using GTK, you would probably also get out the box better performance/power on Wayland since it can take care of partial surface updates etc for you.

WD-424• 11 months ago

Luckily the UI and the core (libghostty) are separate so you can girate out your own UI 101 version without GTK if you'd like.

do_not_redeem• 11 months ago

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

akulbe• 11 months ago

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

mitchellh7• 11 months ago

The only UI Ghostty has is tabs and the context menu

- Tabs

- Splits

- "this process has exited" banner

- Close confirmation dialogs

- Change title dialog

- Unsafe paste detection dialogs

- Context menus

- Animated bells (opt in)

- "Quake-style" dropdown terminals (cross platform but different mechanisms)

- Progress bars (ConEmu OSC 9;4)

- macOS: Apple Shortcuts Integration

- macOS: Spotlight Integration

Probably more I'm not thinking of. It's unfair to say it's just tabs. Could we have done this without a GUI toolkit? Of course! But the whole mission statement of this project was always to use platform-native (for various definitions) toolkits so that it _feels_ native.

That's not for everyone, and that's the great thing about the wonderful vibrant terminal ecosystem we have.

is it really worth the integration pain and now this rewrite?

There's definitely a lot more on the way.

The first goal and primary focus of the project was to build a stable, feature rich (terminal sequences) terminal emulator. We're basically there. Next up, we're expanding GUI functionality significantly, including having more escape sequences result in more native GUI elements. But also traditional things like preferences GUIs, yes.

We're also integrating a lot more deeply with native features provided by each platform (somewhat related to the GUI toolkit choice), such as automatic iCloud syncing of your configuration on macOS. Now that the terminal is stable, we can start to really lean in to application features.

This isn't for everyone. Some people like Kitty's textual tabs. That's fine! It's a tradeoff. That's the beauty of choice. :) Kitty is a great terminal, if you prefer it, please use it. But it has completely different tradeoffs than Ghostty.

LambdaComplex2• 11 months ago

I know I'm about to show my ignorance regarding GUI programming here, but: would SDL2 be a suitable choice? Or would that be too low-level? Or just...the wrong sort of library?

bpbp-mango• 11 months ago

saved sessions in a tree style with folders would be a nice advanced feature!

WesolyKubeczek2• 11 months ago

including having more escape sequences result in more native GUI elements.

That’s how you invent HTML forms (those were modeled on IBM 3270)

Lerc3• 11 months ago

I went on a big meandering hunt for a terminal application that did what I wanted. I have tried many and while nothing perfectly met my needs, Ghostty is the one I am using now.

That counts for something.

Perhaps it is just it lacks an obvious reason to move away from it. Usually, the thing that made me try another terminal was because of something I couldn't do. It wasn't a matter of listing all the pros and cons and going with the best one. It has just found a home with me because it hasn't outstayed its welcome.

alberth• 11 months ago

In addition to what others have said (positively), ‘libghostty’ is also a game changer.

It’s like the “WebKit” for terminal, as I understand it.

Anyone could drop-in libghostty, and immediately have a fully functional terminal.

sevg• 11 months ago

Kovid was able to quickly implement

Is this new account actually Kovid?

Context: “aumerle” had posted only about Kitty for years as though impartial. And talked about Kovid as if they were a different person. Turns out “aumerle” is Kovid and got banned. He was trash-talking ghostty and advertising Kitty in every ghostty thread. (He does the same using “aumerlex” on reddit, but nobody has called him out on there yet.)

I’m suspicious here because Kovid spent hours trying to force me to admit that he writes code faster than Mitchell XD https://news.ycombinator.com/item?id=42567224 (you’ll need “showdead” enabled, all of Kovid’s comments got flagged to death).

iammrpayments• 11 months ago

My font doesn’t look as nice on Kitty as it does on Ghostty. The only place that looks better than ghostty is neovide, but they don’t support tabs yet, and because it is more resource intensive, it drains the battery faster.

crawshaw3• 11 months ago

Nice example of how good programming is often about meeting systems where they are:

  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.

  Well you can avoid it and we did avoid it. And it leads to a mess trying to tie the lifetimes of your non-reference-counted objects to the reference counted ones. There was an entire class of bug that kept popping up in the Ghostty GTK application that could basically be summed up as: the Zig memory or the GTK memory has been freed, but not both.

eviks9• 11 months ago

Giving in a bad system is more pragmatic rather than good

hnlmorg2• 11 months ago

The two terms aren’t mutually exclusive

flohofwoe6• 11 months ago

Careful what you wish for. These days one has to be thankful if a badly designed old system isn't replaced with a new system that's even worse despite the best intentions ;)

crawshaw3• 11 months ago

No, it is about doing what you can, with what you have, where you are. That is good.

renrutal• 11 months ago

Kinda reminds me of a quote attributed to Bjarne Stroustrup:

"There are only two kinds of programming languages: those people always bitch about and those nobody uses"

I feel there are no absolutely "good" systems, only the ones with added compromises over time. Battle scars on a beautiful body.

giancarlostoro3• 11 months ago

GTK having this kind of scheme is why Vala was made and inspired by C# but uses GObject and all its joys, then transpiles your code to C.

This is why a surprising number of GTK applications (more than I realized) are coded in Vala. I lowkey wish they had just adopted D instead of building up Vala. D is basically compiled C# to me in its own ways.

pjmlp7• 11 months ago

The problem is that D community keeps pivoting all the time, so now you get compiled C# with the breath of .NET ecosystem and IDE tooling, and is almost impossible to sell D, even if still has the edge in a few language features.

WCSTombs• 11 months ago

The GTK C API definitely feels like it's begging for a domain-specific language. I guess that language turned out to be Vala, and from what I could see it was a pretty nice language.

My takeaway from all this is a little bit different though: I feel this whole situation ultimately some credence to the Scheme/Racket philosophy, where you can effectively make yourself a domain-specific language without ever leaving the base language. In an alternate universe, we don't choose between adopting D or inventing Vala. We can just stay in Racket.

Lerc3• 11 months ago

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 thought the features that GTK provides were not worth the penalties paid. I have worked around the edges of GTK in open source apps that are GTK based. 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.

I don't hate that GTK exists, It is my choice not to use it and I am fine with that. However I also have encountered people who seem to think it is not my choice not to use it. There are a million and one other GUI toolkits out there, of which GTK is one of the most polished. I can't shake the feeling that if GTK were less dominant, some of the resources that go to polishing GTK might have been spent polishing a different framework with a nicer underlying architecture.

Of course what I consider nicer might not be what others consider nicer. Of those who use GTK, how many use it begrudgingly, and how many feel like it is the best tool for the job?

mitchellh7• 11 months ago

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://ghostty.org/docs/about#native). GTK is by various definitions the most popular, widespread GUI toolkit on Linux that makes your app fit into _most_ ecosystems. So, GTK it is.

I hope `libghostty` will give rise to other apprts (maintained by 3rd parties, it's hard enough for me to maintain macOS and GTK) so that you aren't forced into it. See https://ghostty.org/docs/about#libghostty For example Wraith is a Wayland-native Ghostty frontend (no GTK): https://github.com/gabydd/wraith Awesome.

LambdaComplex2• 11 months ago

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.

AndyKelley5• 11 months ago

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?

Arrowmaster• 11 months ago

You didn't cover it but is Ghostty still entirely dependent on libadwaita for most of its UI features? I completely lost interest when it was still in beta and I found out many features were disabled on Linux if you didn't want it to look and behave as a Gnome app.

aidenn03• 11 months ago

I hate GTK enough that I'm considering porting Ghostty to literally any other GUI system. I think that Qt is probably the only alternative that anyone might consider "platform native" so I'll probably go that direction, even though Qt development is rather special in its own way (you know how GTK decided C needed an object system? Qt decided that C++ needed a more better object system).

account425• 11 months ago

GTK is by various definitions the most popular, widespread GUI toolkit on Linux that makes your app fit into _most_ ecosystems.

I disagree. Qt is also quite popular and much better at adapting to the environment it runs in.

cosmic_cheese2• 11 months ago

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.

bobajeff• 11 months ago

Actually the auto generated bindings can be attributed to the gobject system. It's a very interesting system, similar DCOM in Windows.

Too bad it's so poorly documented. It seems to me like advanced technology left over from a dead civilization, that's being handled by cave people.

ozim2• 11 months ago

Qt licensing is annoying, GTK has its downsides.

So we are left with Electron…

TheDong• 11 months ago

It is my choice not to use it and I am fine with that. However I also have encountered people who seem to think it is not my choice not to use it

I'm curious what the main opposing opinion you've hit there is? Is it accessibility and non-roman-alphabet input? Those are the things that kinda stand out to me as "gtk does this pretty well, and most developers who hand-roll stuff wouldn't think about it".

8f2ab37a-ed6c• 11 months ago

Been a happy Ghostty user for a couple of months, it's my daily driver now as far as macOS terminals go. Thanks for all the hard work Mitchell & team.

schmichael3• 11 months ago

I'm curious if Rust would have prevented the memory correctness errors assuming it replaced Zig in this scenario. It sounds like the vast majority were due to Zig/C interactions which makes me believe Rust would have had the same issues, but as a Go developer I am only guessing. I'm curious if there is a language that provides more tools to ensure correctness even when you're interacting with a huge amount of C.

WD-424• 11 months ago

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.

schmichael3• 11 months ago

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?

mitchellh7• 11 months ago

Hi @schmichael ;) Rust would've prevented one. The rest Rust wouldn't have prevented since as you already noticed, it was in the boundary layer and semantics of a C API. It would've only been as safe as the Rust wrapper. One argument is that the richer, more proven ecosystem of wrapper libraries may have prevented it versus my DIY wrappers.

The one Rust would've prevented was a simple undefined memory access: https://github.com/ghostty-org/ghostty/pull/7982 (At least, I'm pretty sure Rust would've caught this). In practice, it meant that we were copying garbage memory on the first rendered frame, but that memory wasn't used or sent anywhere so in practice it was mostly safe. Still, its not correct!

schmichael3• 11 months ago

Hey Mitchell! Leave it to me to bait the comments. :)

Thanks for validating my assumption that once you introduce a big blob o' C all bets are off and you're back to Valgrind (or similar tooling).

One argument is that the richer, more proven ecosystem of wrapper libraries may have prevented it

Yeah but where's the fun in that? ;)

pornel3• 11 months ago

Rust has safe and reliable GTK bindings. They used gir to auto-generate the error-prone parts of the FFI based on schemas and introspection: https://gtk-rs.org/gir/book/

Rust's bindings fully embrace GTK's refcounting, so there's no mismatch in memory management.

ozgrakkurt• 11 months ago

It is so much more difficult to write c bindings in rust.

Maybe they wouldn’t even be able to write gtk bindings in rust

steveklabnik• 11 months ago

gtk bindings in Rust have existed for like, ten years.

ethan_smith• 11 months ago

Rust would face similar issues. Its safety guarantees only apply within Rust code; the FFI boundary with C/GObject is inherently unsafe and requires manual lifetime management. Rust's borrow checker can't verify external code's memory usage.

WD-424• 11 months ago

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!

mitchellh7• 11 months ago

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.

WD-424• 11 months ago

Looking forward to it!

rvrb3• 11 months ago

I haven't worked with GTK, but what you are describing here sounds reminiscent of what we have been dealing with trying to build Godot bindings in Zig with a nice API. the project is in mid-flight, but Godot:

  - has tons of OOP concepts: classes, virtual methods, properties, signals, etc
  - a C API to work with all of those concepts, define your own objects, properties, and so on
  - manages the lifetimes of any engine objects (you can attach userdata to any of them)
  - a whole tree of reference counted objects

it's a huge headache trying to figure out how to tie it into Zig idioms in a way that is an optimal API (specifically, dealing with lifetimes). we've come pretty far, but I am wondering if you have any additional insights or code snippets I should look at.

working on this problem produced this library, which I am not proud of: https://github.com/gdzig/oopz

here's a snippet that kind of demonstrates the state of the API at the moment: https://github.com/gdzig/gdzig/blob/master/example/src/Signa...

also.. now I want to attempt to write a Ghostty frontend as a Godot extension

aidenn03• 11 months ago

Hopefully it's improved, but the last time I wrote a GTK binding for a language, it was miserable. 98% of it was sane, but the remaining 2% had things like "whether or not this function takes a reference to this object depends on the other parameters passed" which made liveness analysis "interesting."

DanielHB2• 11 months ago

This is what people mean when they say "make invalid states unrepresentable", languages with union types can easily avoid this problem.

poetril• 11 months ago

I did not know this was a project that was in progress, and its quite exciting. I love Godot, and am quite fond a Zig as well. I'll be keeping my eye on this.

Fraterkes• 11 months ago

Thx for the work you're doing! Just out of curiosity, I sometimes struggle to write performant C# Godot code because it's hard to interface with the engine without doing a lot of back and forth conversions to engine types. You end up doing a lot of allocations. Did you run into that kind of stuff while creating your bindings?

rvrb3• 11 months ago

My understanding may be out of date, but the C# support was created before GDExtension existed. The team has been working hard on porting it over to GDExtension. Once they are done, it should be much more performant, and they will finally be able to ship only one version of the editor. I believe the original C# bindings do a lot of unnecessary marshaling at the ABI.

With GDExtension, the core builtin types like `Vector3` are passed by value. Avoid unnecessarily wrapping them in Variant, a specialized tagged union, where you can. You can see the documentation here; you have direct access to the float fields: https://gdzig.github.io/gdzig/#gdzig.builtin.vector3.Vector3

Engine objects are passed around as opaque pointers into engine managed memory. The memory for your custom types is managed by you. You allocate the engine object and essentially attach userdata to it, tagged with a unique token provided to your extension. You can see the header functions that manage this: https://github.com/godotengine/godot/blob/e67074d0abe9b69f3d...

But, this is how the lifetimes for the objects gets slightly hairy (for us, the people creating the language bindings). Our goal with the Zig bindings is to make the allocations and lifetimes extremely obvious, a la Zig's philosophy of "No hidden memory allocations". It is proving somewhat challenging, but I think we can get there.

There's still a lot of surprising or unintuitive allocations that can happen when calling into Godot, but we hope to expose those. My current idea is to accept a `GodotAllocator` on those functions (and do nothing with it; just use it to signal the allocation). You can read the code for the `GodotAllocator` implementation: https://github.com/gdzig/gdzig/blob/master/gdzig/heap.zig#L8...

If we succeed, I think Zig can become the best language to write highly performant Godot extensions in.

jwar767• 11 months ago

We had a similar experience to this at work. We wrote a google cloud service that interfaced with firestore using F# and found it painful because the firestore library is meant to be used with C#. It worked decently well but it was hard to write idiomatic F# without having a bunch of wrapping functions.

Footnote7341• 11 months ago

I managed to write a fairly large GTK application without the GTK type system encroaching on my code at all. It just meant hooking a bunch of lambdas in where they want you to be inheriting from and extending their own classes to allow all the parts to communicate together.

In the end it wasn't that messy, but probably confusing for anyone used to writing dogmatic GTK applications.

LeSaucy• 11 months ago

I'll take QObject over GObject any day of the week.

ripley12• 11 months ago

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

mixmastamyk4• 11 months ago

If it’s not maximized, the space isn’t wasted. The title in the response image looks incredibly crowded. May be ok if several buttons could be removed from the titlebar.

eviks9• 11 months ago

It's literally wasted because it's used for nothing useful. Also, you can have other apps that now can take up less area.

metaltyphoon6• 11 months ago

“Ghostty is cross platform…” but not on windows :D

“App XYZ is mobile ready…” but not on Android.

Same vibe

AndyKelley5• 11 months ago

Windows is becoming less and less of a platform every year

metaltyphoon6• 11 months ago

Not saying you are wrong, but this is akin to “this is the year of the Linux Desktop”.

You probably don’t have this telemetry but have you thought about how having window support helps Zig adoption?

Anecdotal, at day job, we started to use Zig build system to target Windows because that’s where the customers are.

sevensor• 11 months ago

Is that the OS from the people who make Excel?

bitwize3• 11 months ago

I remember the days when "cross-platform" meant it worked on both operating systems: Windows 95 and Windows NT!

epolanski• 11 months ago

Missing windows still means missing most computer users and developers specifically.

keithnz• 11 months ago

WezTerm is a great terminal that IS cross platform and works well on windows (and arguably better than ghostty)

metaltyphoon6• 11 months ago

Yep. I've migrate to it as I need a terminal that is truly cross platform.

WhereIsTheTruth• 11 months ago

Windows is just a web browser, yes i'm serious

bitwize3• 11 months ago

Windows is BonziBuddy with OS functionality attached.

stephen• 11 months ago

I've been using Ghostty, and other GPU-based apps like Alacritty / WezTerm / Zed, because they're ofc better/faster...

Ironically they've all made my DX worse, by highlighting how terrible the nvidia drivers actually worked on both my old Regolith i3wm/compositor-less or new sway/wayland setup.

Like it's ridiculously terrible.

I've tried every magical env flag that Claude can think of, and 4 of the various 550/560/575/580 driver versions--they all suck at screensharing, or resume from sleep, or just out-right buginess/crashes/segfaults in the nvidia drivers.

It must have always been this bad, but I just didn't notice, b/c I never actually used my GPU? lol

aidenn03• 11 months ago

I had a similar experience with Wayland. If I turned compositing effects of in X11, everything worked fine on my two machines (one with a 1050Ti, the other with an AMD card old enough to need the "radeon" driver). Wayland would lag, or crash or just show garbled output.

throw10920• 11 months ago

also verifying with Valgrind every step of the way

This is...both extremely obvious, and also not something that I've ever done before, thought of doing, or seen anyone else do.

Every single instance of Valgrind usage I've encountered or initiated has been triggered by a specific bug or performance regression.

Proactive use of the Valgrind suite (Memcheck and Helgrind at least) as part of the development process would probably result in massively better stability of most tools - and would also make it far easier to find bugs (as you could find them when they were introduced rather than hundreds of commits later).

account425• 11 months ago

I've used Valgrind (mainly memcheck) as a proactive tool or at least as a tool to fish for easy to fix issues before spending too much time debugging specific reports. Main issue is the huge performance overhead that make interactive use under it less than fun - but IMO running your testsuite under it from time to time at least is a no brainer.

ur-whale4• 11 months ago

Proactive use of the Valgrind suite (Memcheck and Helgrind at least) as part of the development process

Yeah, except that it's: slow and expensive and therefore can't be a part of the "short cycle" (edit code, compile, test, iterate) only the "long cycle" (nightly build, test suite). Also valgrind is not exactly designed to directly integrate in a test suite and that requires work.

any1• 11 months ago

I've used valgrind proactively as long as I've been programming in C and C++.

The errors that are caught by valgrind (and asan) will very often not cause immediate crashes or any kind of obvious bugs. Instead, they cause intermittent bugs that are very hard to catch otherwise. They may even be security vulnerabilities.

Another good reason for using it proactively is that small memory leaks tend to sneak in over time. They might not cause any issues and most of them aren't accumulative. However, having all those leaks in there makes it much more difficult to find big leaks when they happen because you have to sift through all the insignificant ones before you can fix the one that's causing problems.

monksy• 11 months ago

Biggest issue I have with Ghostty is that on the mac with Nano.. you can't copy and paste multiple lines into the editor. It's something about how the terminal handles "bracketed pasting".. but yet this isn't an issue with iterm2 and term.

ha1zum• 11 months ago

This could be a valid bug that you can report

dewey• 11 months ago

I've used Ghostty as my default terminal since I set up my new computer a couple of months ago. The only issue I have is the missing search which I often reach for to look through output that I didn't pipe anywhere.

Bit it's also the most mentioned issue: https://github.com/ghostty-org/ghostty/issues/189

scosman• 11 months ago

Agreed. This is the only thing stopping it from being the undisputed best terminal for me. I’ve referred 2 people to it in the last few months, both like it but didn’t adopt it because of this.

qweiopqweiop• 11 months ago

No command f is the killer for me

Sammi• 11 months ago

I can't even open nano in ghostty when I've ssh'd to my ubuntu box:

  $ nano
  Error opening terminal: xterm-ghostty.

Works fine in macos terminal and built in vs code terminal.

biorach5• 11 months ago

Might be $TERM needs to be set or you need to add ghostty to terminfo

ilyagr• 11 months ago

If you're like a quick fix, see https://ghostty.org/docs/help/terminfo#copy-ghostty's-termin.... If that doesn't work, perhaps one of the other suggestions on that page will.

don_searchcraft• 11 months ago

I love 99% of what Ghostty brings to the table as a terminal replacement but the copy / paste issues with it are incredibly frustrating and I run into them almost daily.

egorfine• 11 months ago

I spend like half of my time in the terminal and search is an absolute deal breaker for me. Guys have created an incredibly cool terminal and surely they use it a lot but they... just don't search? I have nothing but respect and admiration for the project, just wondering what their day to day terminal usage experience looks like if they don't need to look for things.

rweichler• 11 months ago

This is now my 5th time writing the GUI part of Ghostty from scratch: [...] once on macOS with SwiftUI, then on macOS with AppKit plus SwiftUI [...]

Ha, that's a nice way of wording that. I'd take it a step or two further. :)

carodgers• 11 months ago

Fun fact. In Ghostty and (some) other GTK apps, if your mouse leaves the window, the first scroll click after re-entering the window is ignored. This is due to an ancient bug first identified in 2015.

https://bugzilla.gnome.org/show_bug.cgi?id=750994

There are no plans for a fix. The maintainer recommends waiting for Wayland.

pilif2• 11 months ago

Reading the report you reference and other issues linked there, I would say that multiple attempts were made to fix it, all of which unfortunately required some heuristics and all of which have broken something else that was deemed worse.

It seems to boil down to an issue in the underlying X11 machinery and it would need to be fixed there first to build a basis on which proper fixes can be implemented.

Given that X11 is in maintenance mode (and as its fans keep saying: It works perfectly fine and doesn't need any more work done on it), it's not likely that's happening.

So, yes, given that information (and I just arrived at that bug report through your post), I would indeed say that waiting for Wayland is the only option they have. All other attempts ended up causing worse issues.

account425• 11 months ago

Other toolkits don't seem to have this issue on X11.

jeroenhd• 11 months ago

From what I can tell, that's an XInput2 bug, not a GTK bug. I suppose GTK can try to implement workarounds like the Chromium heuristic (https://issues.chromium.org/issues/41243294) but the problem lies upstream.

Cloudef2• 11 months ago

Honestly i'd write the UI parts in vala if i'd want to make a gnome native app

zerr2• 11 months ago

For non-UI parts as well, it's a nice language. I wish Windows support was first class though.

WhyNotHugo• 11 months ago

I wouldn’t call GTK the “native” framework on Linux/Wayland or Linux/X11.

Native would be talking to the compositor directly.

GTK provides a cross-platform layer of abstractions over the compositor. That’s the opposite of native.

There’s countless bugs in the Linux port for applications (eg: Firefox) which can’t be fixed because of a he abstractions done by GTK.

lumpa• 11 months ago

    Linux people get really worked up when I say "platform-native". There is no such thing on Linux, but reasonable people agree that something like a GTK app (or Qt) feels "native" on *most desktops* over other applications.

https://mitchellh.com/writing/ghostty-gtk-rewrite#user-conte...

MadcapJake• 11 months ago

"native" here means using the same toolkit as the desktop environment.

tuna742• 11 months ago

There is no "native" compositor for Linux either. The most used one is the one that Android uses.

zerr2• 11 months ago

Wouldn't Vala be a better option instead of Zig?

jiehong• 11 months ago

Speaking of ghostly, I seem to have issues with using Alt shortcuts in helix running in ghostty on Mac OS. I haven’t taken time to investigate more than activating Alt via the option key in Mac.

RGBCube• 11 months ago

You need to enable the option-key-as-alt config option (I recommend only doing it for left option) as alt and option aren't actually the same thing. The name of the config key may be different but it exists

We rewrote the Ghostty GTK application

Related Stories