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

121–130 of 228 posts

Re: We rewrote the Ghostty GTK application

#121

Post by eviks »

gf000 wrote: post #119
eviks wrote: post #74

Earlier quoted context omitted.

You can't put up a PR if the gate keepers reject your whole design approach

Well, yeah. They have their own design approach, if you don't take that into consideration, aren't you the one that in the wrong?

You're not, that depends entirely on the assessment of the relative approaches and whom you care more about, users or a subset of designers closest to the gates.

But that's beside the point, the point was the criticism of the "send a PR" even though that resolves nothing due to the mismatch.

Re: We rewrote the Ghostty GTK application

#122

Post by Sammi »

monksy wrote: post #79

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.

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.

Re: We rewrote the Ghostty GTK application

#123

Post by johnisgood »

account42 wrote: post #110
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…

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

How about wxWidgets or Tcl/Tk or Fyne?

Re: We rewrote the Ghostty GTK application

#124

Post by biorach »

DanielHB wrote: post #107
aidenn0 wrote: post #64

Earlier quoted context omitted.

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

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

It doesn't sound like they are talking about invalid states, more like they are taking about the kind of thing that in Rust would be represented by `Option>` or suchlike. Maybe your point is that in Rust much less ceremony is necessary to avoid hitting a null pointer when doing this. But still, in either language it's easy to end up with hard to follow logic when doing this.

Re: We rewrote the Ghostty GTK application

#125

Post by biorach »

Sammi wrote: post #122
monksy wrote: post #79

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.

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.

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

Re: We rewrote the Ghostty GTK application

#126

Post by wenngle »

biorach wrote: post #125
Sammi wrote: post #122

Earlier quoted context omitted.

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.

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

This. See the ghostty documentation: https://ghostty.org/docs/help/terminfo#ssh

Re: We rewrote the Ghostty GTK application

#127

Post by WhyNotHugo »

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.

Re: We rewrote the Ghostty GTK application

#128

Post by ur-whale »

biorach wrote: post #125
Sammi wrote: post #122

Earlier quoted context omitted.

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.

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

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

Yeah, except that the specific terminfo needed for ghostty isn't installed anywhere on the boxes you ssh into ... you need to manually install it on every single one of them.

That in and of itself makes it truly painful to switch to ghostty.

And there are still a lot of other issues, like e.g. building the tip is a freaking nightmare of dependencies and weird issues (hard reliance on specific versions of the zig compiler and of something called "blueprint compiler", etc...)

Not ready for prime time by a mile IMO.

Re: We rewrote the Ghostty GTK application

#129

Post by ur-whale »

throw10920 wrote: post #70

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

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

Re: We rewrote the Ghostty GTK application

#130

Post by ozim »

microtonal wrote: post #86
ozim wrote: post #83

Earlier quoted context omitted.

Qt licensing is annoying, GTK has its downsides. So we are left with Electron…

Aren't GTK and Qt (community edition) both LGPL (though different versions)? So Electron does not have downsides? Like far worse platform integration.

Well Qt license is not annoying.

Qt the company is annoying because they make it super hard to use community edition and it is super annoying having per developer licensing with all kinds of super annoying BS one have to deal with when developing for Qt.

For Electron I can get 20 devs hired tomorrow or I myself can start project right away and be up and running in minutes.

Post reply on HN