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

221–228 of 228 posts

Re: We rewrote the Ghostty GTK application

#221

Post by giancarlostoro »

pjmlp wrote: post #194
giancarlostoro wrote: post #193

Earlier quoted context omitted.

I'm not talking about merging .NET into D I'm talking about instead of building Vala which transpiles to C, the creators of Vala could have just made a D library instead. D does not need the .NET ecosystem to survive.

Neither am I. D needs a usable ecosystem, the point is that since Andrei Alexandrescu's book came out, the incomplete pivots have allowed the competition to get most of D features where it had an edge back 15 years ago. Even Andrei eventually got back to C++, now working at NVidia. Native AOT or .NET Native, plus all the Midori related improvements, and everything else C# has access to, was one example, there are oth…

Ah I understand. Yeah, what D needs is to build up a STD lib comparable to Go’s which lets you build nearly anything OOTB without a fuzz.

Re: We rewrote the Ghostty GTK application

#222

Post by mariusor »

metaltyphoon wrote: post #218
Zambyte wrote: post #203

Earlier quoted context omitted.

Is it? I've heard of people using a non-Microsoft terminal on Windows besides git bash and cygwin probably no more often than I could count on one hand. And people don't ever use those for the terminal, but usually for GNU. On the other hand, I find it uncommon to see anyone who chooses to use a terminal regularly using the MacOS default terminal, and there is no default Linux terminal. I find it hard to imagine a wo…

Anyone that started computing using DOS is very aware of terminals. > I find it uncommon to see anyone who chooses to use a terminal regularly using the MacOS default terminal If you are going to say that about windows the same could be said about macOS. In fact, I only know of one mac user within my circle that has used the non default terminal. Anecdotally, at day job, every terminal I see on windows is riced out.…

Those millions of users are not at your job, they are not programmers, and they don't use the terminal.

Re: We rewrote the Ghostty GTK application

#223

Post by egorfine »

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

Re: We rewrote the Ghostty GTK application

#224

Post by ilyagr »

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.

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.

Re: We rewrote the Ghostty GTK application

#225

Post by [deleted] »

nothankyou777 wrote: post #210
tristan957 wrote: post #209

Earlier quoted context omitted.

I don't think you know enough about GTK if you think having a CSS parser is bloat in a UI toolkit versus a whole theming engine.

Their CSS implementation is broader than what most actual browsers had 10 years ago. I would not have commented if I weren't already painfully familiar. https://docs.gtk.org/gtk3/css-overview.html It even has a DOM inspector window: https://askubuntu.com/questions/597259/how-do-i-open-gtk-ins...

[deleted]

Re: We rewrote the Ghostty GTK application

#226

Post by antihero »

AndyKelley wrote: post #101
antihero wrote: post #95

Earlier quoted context omitted.

How would this work given that the major DE's have completely different UX and design?

That's precisely the point! It would be really nice for applications to be able to operate agnostic from the DE's decisions about UX and design. Applications want something much more high level: button here, scroll bar there, text input here. It's the DE's job to make such things accessible and look pretty. If you think about it, that's precisely why the web is a popular user interface target: the application has a m…

No it is the developer's job to make things be nice and work well. We've gone past pretending to be native shit for pretty much everything. We define our own design styles and language since the web took off.

Re: We rewrote the Ghostty GTK application

#227

Post by codethief »

AndyKelley wrote: post #196
jon-wood wrote: post #106

Earlier quoted context omitted.

I don’t think it’s possible to build a generic UI across DEs, at least if you actually want them to feel native. They’ve all got different standards, so while Gnome might have a button here, a text box here, and scroll bar there on KDE a scroll bar here, text box here, and then the button might make more sense.

My point is that the application doesn't have to care if it's running in Gnome or KDE. It just speaks Wayland protocol and then it gets a Window and some UI in it. The gnome window manager / KDE window manager then makes that UI properly native. Consider input methods. That clearly belongs in the window manager process, not each application process. The application should simply ask for a text box, and then receive e…

I like the idea but, having built many UIs for many different applications over the years, I doubt it would work for anything non-trivial. The thing is, as soon as your UI reaches a certain level of complexity you need tight control over the look and feel, especially over the positioning of UI components relative to each other. Unfortunately, the latter depends a lot on how exactly your UI components look and behave.

For example, your text input box's label might be displayed to the left of the box, to the top, or it might be one of those floating labels that are displayed inside the box but move to the top border as soon as you focus the box. Depending on that, you would choose the spacing to neighboring text boxes and buttons differently, and maybe also arrange things differently altogether, because of different space requirements.

In other words: Your application would need to know what exactly the Wayland "UI layer" is going to display in order to send it precise instructions. But then your abstraction is very leaky.

Re: We rewrote the Ghostty GTK application

#228

Post by antihero »

AndyKelley wrote: post #196
jon-wood wrote: post #106

Earlier quoted context omitted.

I don’t think it’s possible to build a generic UI across DEs, at least if you actually want them to feel native. They’ve all got different standards, so while Gnome might have a button here, a text box here, and scroll bar there on KDE a scroll bar here, text box here, and then the button might make more sense.

My point is that the application doesn't have to care if it's running in Gnome or KDE. It just speaks Wayland protocol and then it gets a Window and some UI in it. The gnome window manager / KDE window manager then makes that UI properly native. Consider input methods. That clearly belongs in the window manager process, not each application process. The application should simply ask for a text box, and then receive e…

> makes that UI properly native

That's five words with unimaginable complexity.

Post reply on HN