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

111–120 of 228 posts

Re: We rewrote the Ghostty GTK application

#111

Post by Fraterkes »

rvrb wrote: post #15

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

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?

Re: We rewrote the Ghostty GTK application

#112

Post by account42 »

king_geedorah wrote: post #40
AndyKelley wrote: post #31

Earlier quoted context omitted.

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?

No, there are no protocols intended to implement such a thing at this time. I'm not aware of anybody attempting to spec out such a protocol either, but I do think it's a really interesting idea. Edit: s/protocol/interface

There is about zero chance that Gnome would implement such a protocol which makes the whole endeavor pointless. They can't even agree on server side window decorations.

Re: We rewrote the Ghostty GTK application

#113

Post by account42 »

flohofwoe wrote: post #105
AndyKelley wrote: post #31

Earlier quoted context omitted.

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?

I don't think we will even see universal support for server-side window decorations in our lifetime, so don't hold your breath ;) (yes I'm aware of libdecor, but it sucks to have to pull in yet another complex dependency into clients)

While pulling in a library just for window decorations is insane, the same could make sense for a full UI toolkit - after all, that's how standard UI components have worked on e.g. Windows. In a way, Qt can already fulfill that role because by default it tries to adapt to the look and feel of the platform it runs on, including using GTK themes. Too bad that it's a bloated pig without a stable ABI that would allow you to use the system version.

Re: We rewrote the Ghostty GTK application

#114

Post by ChocolateGod »

Fnoord wrote: post #100
hactually wrote: post #42

Earlier quoted context omitted.

Can you do that on Windows/mac? Gnome devs not withstanding, you have access to the source to change it if you want or put up a PR?

2025, still cannot have taskbar on left or right side in Windows 11. I can do that on GNOME and macOS. And yes, with 21:9 it is very nice. With a vertical monitor or a 3:2 (Surface), not so much.

You have to install an extension to do that on GNOME, likewise on Windows 11 you can use Explorer Patcher.

Both "monkey patch" the shell.

Re: We rewrote the Ghostty GTK application

#115

Post by huimang »

mixmastamyk wrote: post #76
eviks wrote: post #75

Earlier quoted context omitted.

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

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

Many people use tiling window managers, so title bars become useless. The first thing I did in configuring ghostty was disabling window decoration for this reason.

Re: We rewrote the Ghostty GTK application

#116

Post by bpbp-mango »

mitchellh wrote: post #7
corsica wrote: post #2

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

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

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

Re: We rewrote the Ghostty GTK application

#117

Post by account42 »

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…

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.

Re: We rewrote the Ghostty GTK application

#118

Post by ozgrakkurt »

schmichael wrote: post #12

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.

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

Re: We rewrote the Ghostty GTK application

#119

Post by gf000 »

eviks wrote: post #74
hactually wrote: post #42

Earlier quoted context omitted.

Can you do that on Windows/mac? Gnome devs not withstanding, you have access to the source to change it if you want or put up a PR?

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?

Re: We rewrote the Ghostty GTK application

#120

Post by flohofwoe »

account42 wrote: post #113
flohofwoe wrote: post #105

Earlier quoted context omitted.

I don't think we will even see universal support for server-side window decorations in our lifetime, so don't hold your breath ;) (yes I'm aware of libdecor, but it sucks to have to pull in yet another complex dependency into clients)

While pulling in a library just for window decorations is insane, the same could make sense for a full UI toolkit - after all, that's how standard UI components have worked on e.g. Windows. In a way, Qt can already fulfill that role because by default it tries to adapt to the look and feel of the platform it runs on, including using GTK themes. Too bad that it's a bloated pig without a stable ABI that would allow you…

> after all, that's how standard UI components have worked on e.g. Windows

Standard UI components on Windows are in user32.dll, and that's guaranteed to exist on each Windows installation all the way back to Windows NT.

And to just get an empty decorated window all I need to do is call CreateWindowEx() (which will always look consistent), all the rendering inside that window can then be done through one of the 3D APIs.

Same on macOS, I don't need any optional dependencies to create a decorated empty window which I can then render into with Metal.

For that same scenario (3D rendering into an empty window), Wayland only guarantees me a bare undecorated rectangle I can draw into with GL or Vulkan (and I wouldn't be surprised if even that is an optional feature I need to query first lol). And even if both GTK and Qt would be guaranteed to be installed on each Linux desktop system (so that I can pick one of two frameworks to give me a dedorated window, that would be overkill if I just want an empty window for 3D rendering - and even then I don't know if a window created through Qt would look consistent on a GNOME desktop or vice versa).

Of course that topic has been discussed to death without anybody who could fix that problem once and for all (by making the server-side decoration extension mandatory for desktop Linux systems) even recognizing that this is an issue that needs fixing.

Tbh, I don't even understand why desktop Linux needs more than a single Wayland implementation. So much wasted redundant work which could be put into actual improvements.

Post reply on HN