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

191–200 of 228 posts

Re: We rewrote the Ghostty GTK application

#191

Post by skydhash »

flohofwoe wrote: post #174
skydhash wrote: post #167

Earlier quoted context omitted.

I’m not a maintainer, but IMO, it may be the different design systems. Yes there are common elements like buttons and scrolled view. But the whole selling point of a toolkit is consistency, especially around more advanced widgets.

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

Re: We rewrote the Ghostty GTK application

#192

Post by tristan957 »

nothankyou777 wrote: post #190
tristan957 wrote: post #187

Earlier quoted context omitted.

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.

You didn't explain anything wrong with GTK. You just brought up Electron out of nowhere.

Re: We rewrote the Ghostty GTK application

#193

Post by giancarlostoro »

pjmlp wrote: post #183
giancarlostoro wrote: post #144

Earlier quoted context omitted.

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.

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.

Re: We rewrote the Ghostty GTK application

#194

Post by pjmlp »

giancarlostoro wrote: post #193
pjmlp wrote: post #183

Earlier quoted context omitted.

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.

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 others from other ecosystems.

Re: We rewrote the Ghostty GTK application

#195

Post by nothankyou777 »

tristan957 wrote: post #192
nothankyou777 wrote: post #190

Earlier quoted context omitted.

Are we looking at the same title? We rewrote the Ghostty *G* *T* *K* application The article about struggling... with GTK.

You didn't explain anything wrong with GTK. You just brought up Electron out of nowhere.

Electron is bringing an entire web browser in to provide a cross-platform user interface. GTK has become almost a web browser to provide a cross-platform user interface. That is why I started off with

> CSS classes

To spell it out, I think it is all excessive.

Re: We rewrote the Ghostty GTK application

#196

Post by AndyKelley »

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

Earlier quoted context omitted.

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.

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 events when the text in the box changes. The fact that I'm typing Japanese into a fancy UI shouldn't make any difference to the application, other than what text it receives from the widget events.

And that should all be possible in a small, static executable, that is speaking the Wayland protocol, and has zero dependencies other than networking syscalls.

Re: We rewrote the Ghostty GTK application

#199

Post by codethief »

LambdaComplex wrote: post #29
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 like Linux because it gives me the freedom to make my system behave how I want. The GNOME devs seem to think that GNOME should only behave how they want. For example, last time I checked, GNOME required a third-party plugin just to move the clock from the center of the status bar to the side. I'm not at all surprised to see that this mindset extends to GTK.

> The GNOME devs seem to think that GNOME should only behave how they want.

For many years I followed this whole outrage but wasn't really sure whom to believe because I didn't have any stakes in the matter. Then the GNOME/GTK devs removed support for key themes[0,1] and I still have no idea why. The arguments they brought forward make absolutely no sense to me.

Now I get where people were coming from.

[0]: https://old.reddit.com/r/emacs/comments/c22ff1/gtk_4_support...

[1]: https://news.ycombinator.com/item?id=35702303

Re: We rewrote the Ghostty GTK application

#200

Post by tuna74 »

WhyNotHugo wrote: post #127

I wouldn’t call GTK the “native” framework on Linux/Wayland or Linux/X11. Native would be talking to the compositor directly. GTK provides a cross-platform layer of abstractions over the compositor. That’s the opposite of native. There’s countless bugs in the Linux port for applications (eg: Firefox) which can’t be fixed because of a he abstractions done by GTK.

There is no "native" compositor for Linux either. The most used one is the one that Android uses.
Post reply on HN