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

211–220 of 228 posts

Re: We rewrote the Ghostty GTK application

#211

Post by t_mahmood »

LambdaComplex wrote: post #30
mitchellh wrote: post #7

Earlier quoted context omitted.

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

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?

Just from my basic understanding after working with sdl2 and gtk, sdl2 is more suitable for game development, It doesn't have standard set of UI elements. So every UI element, and interactions will have to be implemented by hand. Now imagine displaying a list view with huge number of items.

And the worst is, Terminals works with texts, sdl2, in my knowledge do not have proper way to display large amount of text, let alone select and copy.

There are probably other issues, these came from what I experienced

Re: We rewrote the Ghostty GTK application

#212

Post by JoyceBabu »

bitwize wrote: post #99
WhereIsTheTruth wrote: post #84

Earlier quoted context omitted.

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

Windows is BonziBuddy with OS functionality attached.

BonziBuddy. I remember using it long back, was fun back then. Later heard that they injected malicious code into the software.

Re: We rewrote the Ghostty GTK application

#213

Post by pjmlp »

rvrb wrote: post #188
pjmlp wrote: post #182

Earlier quoted context omitted.

Another thing it does badly and I am not sure if they are sorting out with the new design, is the magic methods crap. They had to copy that bad idea from Unity, where methods are named in a specific way and then extracted via reflection. Either provide specific interfaces that components have to implement, use attributes, or make use of generics with type constraints. Maybe for Unity that made sense as they started w…

> extracted via reflection I think you are talking about dispatch of virtual methods, which is still a thing, but the performance cost can be somewhat mitigated. the names of the methods are interned strings (called `StringName`). a naive implementation will allocate the `StringName`, but you can avoid the allocation with a static lifetime string. we expose a helper for comptime strings in Zig[0]. then, extension cla…

That and the exposition of _Something methods in C#, which don't follow C# conventions, private/protected methods have keywords for that.

Thanks for the overview.

Re: We rewrote the Ghostty GTK application

#214

Post by flohofwoe »

skydhash wrote: post #191
flohofwoe wrote: post #174

Earlier quoted context omitted.

> But the whole selling point of a toolkit is consistency, especially around more advanced widgets. In theory yeah, but that consistency is out the window anyway when some apps I'm using are GTK, others Qt, and yet others Electron with the JS framework flavour of the week. A standard shim library which would map to the user's preferred framework (e.g. GTK or Qt) would at least be visually consistent between GTK and Q…

Why don't the developer do the shim themselves? You can always have a core and shell out the UI to the platform being used. One example is Celluloid [0] (GTK) and IINA [1], both use mpv as their backend. Why not have something like libslack, libspotify (a real one), or libdiscord, then have a more appropriate frontend to meet the users where they are. [0]: https://celluloid-player.github.io/ [1]: https://iina.io/

...more code in the client that should really be part of the 'operating system', and if I need to do it myself anyway, why should I care about consistency with other applications?

Such an idea only works if it is less work for application developers, not more. And I think the right place for that is the operating system layer, not the application layer.

Re: We rewrote the Ghostty GTK application

#215

Post by skydhash »

flohofwoe wrote: post #214
skydhash wrote: post #191

Earlier quoted context omitted.

Why don't the developer do the shim themselves? You can always have a core and shell out the UI to the platform being used. One example is Celluloid [0] (GTK) and IINA [1], both use mpv as their backend. Why not have something like libslack, libspotify (a real one), or libdiscord, then have a more appropriate frontend to meet the users where they are. [0]: https://celluloid-player.github.io/ [1]: https://iina.io/

...more code in the client that should really be part of the 'operating system', and if I need to do it myself anyway, why should I care about consistency with other applications? Such an idea only works if it is less work for application developers, not more. And I think the right place for that is the operating system layer, not the application layer.

Yes, but Linux is only the kernel, everything else is someone else project. A distribution is nothing else than a curated list of software projects.

macOS is a good example of what you're proposing. The developer toolkit have a lot of nice frameworks (libraries) to help build apps. But that ties you to Apple. You can't expect consistencies across OS unless someone does the work to provide an intermediate layer, and then you loose on each OS nicest capabilities.

It may not make business sense, but the most elegant solution is to have a core that is your feature set, and then flesh out each dependency according to the platform.

Re: We rewrote the Ghostty GTK application

#216

Post by RGBCube »

jiehong wrote: post #205

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.

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

Re: We rewrote the Ghostty GTK application

#217

Post by [deleted] »

Zambyte wrote: post #203
metaltyphoon wrote: post #202

Earlier quoted context omitted.

This is a wild take.

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…

[deleted]

Re: We rewrote the Ghostty GTK application

#218

Post by metaltyphoon »

Zambyte wrote: post #203
metaltyphoon wrote: post #202

Earlier quoted context omitted.

This is a wild take.

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. The Windows terminal app video from MS probably helped with that lol.

Re: We rewrote the Ghostty GTK application

#219

Post by bgribble »

aidenn0 wrote: post #66
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 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).

I feel some genuine grief about what GTK has become.

It started out as a toolkit for application development and leaned heavily into the needs of the C developer who was writing an application with a GUI. It was really a breath of fresh air to us crusties who started out with Xaw and Motif. That's the GTK I want to remember.

What it is now is (IMO) mostly a product of the economics of free software development. There's not a lot of bread out there to build a great, free, developer experience for Linux apps. Paid GTK development is just in service of improving the desktop platform that the big vendors ship. This leads to more abstraction breaks between the toolkit, the desktop, and the theme, because nobody cares as long as all the core desktop apps work. "Third party" app developers, who used to be the only audience for GTK, are a distant second place. The third party DX is only good if you follow a cookie-cutter app template.

I switched my long-term personal projects from GTK2 to Dear ImGui, which IMO is the only UI toolkit going that actually prioritizes developer experience. Porting from GTK2 to GTK3 would have been almost as much work since I depended on Clutter (which was at one point a key element of the platform, but got dropped/deprecated -- maybe its corporate sponsor folded? not sure).

Re: We rewrote the Ghostty GTK application

#220

Post by mixmastamyk »

eviks wrote: post #80
mixmastamyk wrote: post #76

Earlier quoted context omitted.

Titlebars are quite useful, I use them frequently to move, raise, lower, and maximize windows.

Oh sure, but some people use more ergonomic ways to perform those actions, so to them the title bars would be a waste even if not maximized

Nothing more “ergonomic” than a titlebar. Discoverable, standard, usable.
Post reply on HN