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

101–110 of 228 posts

Re: We rewrote the Ghostty GTK application

#101

Post by AndyKelley »

antihero wrote: post #95
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?

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 much higher level interface, and all those concerns are, correctly, handled at a different abstraction layer.

Re: We rewrote the Ghostty GTK application

#102

Post by pilif »

carodgers wrote: post #89

Fun fact. In Ghostty and (some) other GTK apps, if your mouse leaves the window, the first scroll click after re-entering the window is ignored. This is due to an ancient bug first identified in 2015. https://bugzilla.gnome.org/show_bug.cgi?id=750994 There are no plans for a fix. The maintainer recommends waiting for Wayland.

Reading the report you reference and other issues linked there, I would say that multiple attempts were made to fix it, all of which unfortunately required some heuristics and all of which have broken something else that was deemed worse.

It seems to boil down to an issue in the underlying X11 machinery and it would need to be fixed there first to build a basis on which proper fixes can be implemented.

Given that X11 is in maintenance mode (and as its fans keep saying: It works perfectly fine and doesn't need any more work done on it), it's not likely that's happening.

So, yes, given that information (and I just arrived at that bug report through your post), I would indeed say that waiting for Wayland is the only option they have. All other attempts ended up causing worse issues.

Re: We rewrote the Ghostty GTK application

#103

Post by flohofwoe »

eviks wrote: post #73
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…

Giving in a bad system is more pragmatic rather than good

Careful what you wish for. These days one has to be thankful if a badly designed old system isn't replaced with a new system that's even worse despite the best intentions ;)

Re: We rewrote the Ghostty GTK application

#104

Post by hnlmorg »

eviks wrote: post #93
hnlmorg wrote: post #91

Earlier quoted context omitted.

The two terms aren’t mutually exclusive

Only in a dictionary. In a sentence that has the context of a poorly designed system, they are because you explicitly have to do worse programming to meet the system at a worse point

“Good” and “bad” are subjective.

Being pragmatic about the design of an ecosystem and working with it, could be seen as good programming vs the alternative of fighting that ecosystem and thus creating entirely new classes of bugs.

And this was what the GP was responding to. They were was that the pragmatism of working with that ecosystem showed good judgement.

Re: We rewrote the Ghostty GTK application

#105

Post by flohofwoe »

AndyKelley wrote: post #31
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…

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)

Re: We rewrote the Ghostty GTK application

#106

Post by jon-wood »

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…

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.

Re: We rewrote the Ghostty GTK application

#107

Post by DanielHB »

aidenn0 wrote: post #64
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…

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.

Re: We rewrote the Ghostty GTK application

#108

Post by epolanski »

AndyKelley wrote: post #49
metaltyphoon wrote: post #43

“Ghostty is cross platform…” but not on windows :D “App XYZ is mobile ready…” but not on Android. Same vibe

Windows is becoming less and less of a platform every year

Missing windows still means missing most computer users and developers specifically.

Re: We rewrote the Ghostty GTK application

#109

Post by account42 »

pilif wrote: post #102
carodgers wrote: post #89

Fun fact. In Ghostty and (some) other GTK apps, if your mouse leaves the window, the first scroll click after re-entering the window is ignored. This is due to an ancient bug first identified in 2015. https://bugzilla.gnome.org/show_bug.cgi?id=750994 There are no plans for a fix. The maintainer recommends waiting for Wayland.

Reading the report you reference and other issues linked there, I would say that multiple attempts were made to fix it, all of which unfortunately required some heuristics and all of which have broken something else that was deemed worse. It seems to boil down to an issue in the underlying X11 machinery and it would need to be fixed there first to build a basis on which proper fixes can be implemented. Given that X11…

Other toolkits don't seem to have this issue on X11.

Re: We rewrote the Ghostty GTK application

#110

Post by account42 »

mitchellh wrote: post #11
Lerc wrote: post #6

> 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. In the past this has also been my assessment of GTK. It lead me to decide to take the other path, to never directly use GTK. I appreciate the value in having a unified user interface between applications, but I have always tho…

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

Post reply on HN