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

181–190 of 228 posts

Re: We rewrote the Ghostty GTK application

#181

Post by cosmic_cheese »

ogoffart wrote: post #166
microtonal wrote: post #146

Earlier quoted context omitted.

Yep, externalization of costs, make it easier for yourself and shittier for the user. Well done ;). That said, Electron has made the number of Linux apps go up, which is a win. Still highly prefer native macOS apps on Mac and GTK/Qt apps on Linux, but I know that's a losing battle.

Did you know about Slint https://slint.dev ? What do you think about it?

I don’t think any UI framework with a license more restrictive or complicated than full on MIT/BSD is going to be able to compete toe to toe with Electron. It doesn’t matter what the price tag is, if it has one it’s going to lose in a shootout between the two.

The only exception I can imagine is maybe a framework that uses the Unreal model, where it’s free to use under USD$1m/year in revenue and beyond that requires only a modest fee.

Re: We rewrote the Ghostty GTK application

#182

Post by pjmlp »

rvrb wrote: post #180
Fraterkes wrote: post #111

Earlier quoted context omitted.

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?

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 `Vect…

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 with scripting languages, and then bolted on Mono on the side, but it never made sense to me.

Re: We rewrote the Ghostty GTK application

#183

Post by pjmlp »

giancarlostoro wrote: post #144
crawshaw wrote: post #3

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

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.

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.

Re: We rewrote the Ghostty GTK application

#184

Post by pjmlp »

bobajeff wrote: post #45
cosmic_cheese wrote: post #38

Earlier quoted context omitted.

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

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.

COM, not DCOM, that would be D-BUS.

Re: We rewrote the Ghostty GTK application

#185

Post by pjmlp »

ozim wrote: post #83
cosmic_cheese wrote: post #38

Earlier quoted context omitted.

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

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

I still rather deal with either Qt or Gtk, even though Web pays the bills.

No one is pointing guns forcing people to write Electron crap.

Re: We rewrote the Ghostty GTK application

#186

Post by pjmlp »

pornel wrote: post #69
ericbarrett wrote: post #26

Earlier quoted context omitted.

Do you mean gtk-rs ( https://gtk-rs.org/ )? I have done a bit of programming with it. I respect the work behind it, but it is a monumental PITA - truly a mismatch of philosophies and design - and I would a thousand times rather deal with C/C++ correctness demons than attempt it again, unless I had hard requirements for soundness. Even then, if you use gtk-rs you are pulling in 100+ crate dependencies and who knows wh…

Yeah, Rust isn't OOP, which is usually fine or even an advantage, but GUIs are one case where it hurts, and there isn't an obvious alternative. > gtk-rs you are pulling in 100+ crate dependencies and who knows what lurks in those? gtk-rs is a GNOME project. A lot of it is equivalent to .h files, but each file is counted as a separate crate. The level of trust or verification required isn't that different, especially…

Rust has all the features to do COM and CORBA like OOP.

As Windows proves, it is more than enough to write production GUI components, and the industry leading 3D games API, since the days of Visual Basic 5.

In fact that is how most new Rust components on Windows by Microsoft have been written, as COM implementations.

Re: We rewrote the Ghostty GTK application

#187

Post by tristan957 »

nothankyou777 wrote: post #143
mitchellh wrote: post #63

Earlier quoted context omitted.

Yes, its a hard dependency. But we go out of our way to add CSS classes to our UI widgets and even have a configuration in Ghostty to supply custom CSS directly (without you having to mess with gsettings or anything). We've seen some pretty incredible customizations in our showcase channel in Discord. We haven't committed to our CSS classes yet as a stable API but we plan to do that in the next release cycle. Still,…

> CSS classes GTK has gotten so fat that it's more like a 2nd-rate Electron. Not that Electron would have done Ghostty any good... I have a bad feeling that the only decent & consistent UI option under Linux is to target Win32 API, then run it under Wine.

What does this have to do with Ghostty?

Re: We rewrote the Ghostty GTK application

#188

Post by rvrb »

pjmlp wrote: post #182
rvrb wrote: post #180

Earlier quoted context omitted.

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 `Vect…

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 classes need to provide callback(s)[1] on registration that lookup and call the virtual methods. as far as I know, the lookup happens once, and the engine stores the function pointer, but I haven't confirmed this yet. it would be unfortunate if not.

at least right now in GDZig, though this might change, we use Zig comptime to generate a unique function pointer for every virtual function on a class[2]. this implementation was by the original `godot-zig` author (we are a fork). in theory we could inline the underlying function here with `@call(.always_inline)` and avoid an extra layer indirection, among other optimizations. it is an area I am still figuring out the best approach for

virtual methods are only ever necessary when interfacing with the editor, GDScript, or other extensions. don't pay the cost of a virtual method when you can just use a plain method call without the overhead.

[0]: https://gdzig.github.io/gdzig/#gdzig.builtin.string_name.Str...

[1]: https://github.com/godotengine/godot/blob/e67074d0abe9b69f3d...

[2]: https://github.com/gdzig/gdzig/blob/5abe02aa046162d31ed5c52f...

Re: We rewrote the Ghostty GTK application

#189

Post by tristan957 »

ur-whale wrote: post #128
biorach wrote: post #125

Earlier quoted context omitted.

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

I don't think you've used Ghostty in a while. It has auto installing terminfo when ssh-ing.

Also, every program ever depends on a certain version of a compiler, so I don't understand this complaint. Ghostty requires Zig 0.14. That's it, not a specific compiler hash. blueprint-compiler is packaged for pretty much every distribution these days.

Re: We rewrote the Ghostty GTK application

#190

Post by nothankyou777 »

tristan957 wrote: post #187
nothankyou777 wrote: post #143

Earlier quoted context omitted.

> CSS classes GTK has gotten so fat that it's more like a 2nd-rate Electron. Not that Electron would have done Ghostty any good... I have a bad feeling that the only decent & consistent UI option under Linux is to target Win32 API, then run it under Wine.

What does this have to do with Ghostty?

Are we looking at the same title?

We rewrote the Ghostty *G* *T* *K* application

The article about struggling... with GTK.

Post reply on HN