Comment by quotemstr | Hacker News Reader

Comment by quotemstr | Hacker News Reader

Parent Full thread

The GTK 4 transition is totally unnecessary. Any new functionality needed can be incorporated into the existing API in a backwards-compatible manner. Major version bumps should be an absolute last resort, not something a major infrastructure library does when it gets too stable and its developers get bored.

You want a new recyclerview-like list widget? Great. Make a new damned widget. You want a retained-mode rendering system? Great! Add a bunch of new widget hooks. Don't require a whole new major version bump and make everyone using GTK3 deal with dependency hell trying to get upgraded. It feels like only yesterday that most things finally moved off GTK2.

There is ZERO reason for an ABI break here. None. GTK3's ABI is a perfectly adequate base for adding new functionality. The GTK people, by making a GTK4, made a lot of work for everyone for no benefit.

Is the GTK4 API cleaner? I guess? Event objects are opaque now. There's no root window. Yay? But "it looks slightly cleaner" is a totally inadequate justification for the pain of yet another GTK ABI transition.

I could go and on about how much gratuitous breaking changes piss me off.

The same goes for Wayland, by the way --- X11 has an extension mechanism. Wayland could have used it. And don't tell me about the core protocol breaking the model --- it doesn't hurt anything if you don't use it.

X has serious architectural problems. What would it mean to build a completely new windowing API using the extension system, if 'proper use' would mean using exclusively the new extended API? Is that meaningfully different from or better than building a new windowing system (cf wayland) and implementing x11 on top of it (cf xwayland)?

FWIW, I think wayland also has serious architectural problems, and see arcan as much more promising, but rewriting/replacing legacy can definitely be justified. Extension hell is much worse than compatibility hell. If you don't like gtk4's api, then don't use it; gtk3 will continue to work. It's better that an api should be coherent and cohesive than that it should bend over backwards to keep compatibility with ideas that no longer make sense. Obviously, this should be applied within reason—don't do a complete rearchitecture every month—but compatibility breaks are important and necessary.

> if 'proper use' would mean using exclusively the new extended API? Is that meaningfully different from building a new windowing system (cf wayland) and implementing x11 on top of it (cf xwayland)?

We're already in a world where "proper use" of X11 means relying on ubiquitous extensions. Nobody uses the core font rendering APIs anymore --- instead, everyone uses fontconfig and XRENDER. The transition was gradual and smooth. Nobody had to rewrite applications. Both old-font-API and new-font-API X11 applications shared the same X server, the same connectivity configuration.

The transition to Wayland should have looked like a super-XRENDER, not some bespoke new thing with an embedded X server that will always be a second-class citizen just like embedded X servers on Windows and macOS are.

Making some grand new thing and emulating the legacy thing is harder to get right than just teaching the legacy thing to do something new. Why? Because in any rewrite, you not only have to rewrite the parts of the old system that are bad, but also the parts that are good.

Yet the people who were working on Xorg decided to write wayland instead. Why? Because there was little more benefit to he had from the previous approach. Xorg had become a slow and bloated synchronous IPC service and replacing it with a UNIX pipe was the logical solution.

> Xorg had become a slow and bloated synchronous IPC service and replacing it with a UNIX pipe was the logical solution.

You do realize the the X11 server connection is also almost always a Unix socket, right? (ITYM "Unix socket", not "Unix pipe".) That's like showing out your spork and replacing it with a spork.

> Yet the people who were working on Xorg decided to write wayland instead.

My whole point is that they were wrong to do so, just like I think the GTK people are wrong to break ABI on GTK4.

A completely new solution was inevitable because there was nothing more that could be done with Xorg. All of the complexity that mattered had moved into the WM, Compositor or Client. It wasn't actually doing anything anymore.

> A completely new solution was inevitable because there was nothing more that could be done with Xorg.

I see no evidence behind this assertion. What specifically would have prevented the further evolution of Xorg?

> All of the complexity that mattered had moved into the WM, Compositor or Client.

Good. So that means that Xorg didn't have to change very much. All Xorg had to do is provide mechanism, not policy, and let WM, compositor, and client cooperate as they've been doing for decades.

But instead the Xorg maintainers got bored and decided to make a big ball of mud with no separation of concerns.

> The same goes for Wayland, by the way

Wayland happened mainly because they could get to 90% of Xorg functionality easily and ignored the fact that the last 10% would take over a decade to achieve parity on.

> Wayland happened mainly because they could get to 90% of Xorg functionality easily

We're at 12 years of Wayland and counting and the thing still isn't really usable outside a very narrow use-case. I still run X11 myself and will for a long time. As far as I'm concerned, Wayland has set free software windowing back by a decade. After all this time, Wayland still isn't at parity with X11 even for use cases that Wayland intends to support --- and some things that X11 can do are non-goals for Wayland and will never be supported. What exactly is so compelling in Wayland that it was worth putting progress on hold since 2008?

Yeah, yeah, I get that Wayland has a nice buffer-based composition system. So what? Whatever Wayland does, it could have done over an X11 extension.

Wayland was the default in Ubuntu 17 and is still the default in Fedora. I like it because dealing with multiple displays and tearing under X annoys me more than dealing with screen capture under Wayland. “Not really usable outside a very narrow use-case” overstates the problem.

While I totally agree with you in a desktop-like scenario, please note that X is totally inadequate and bloated for other domains (e.g. automotive).

As the other poster mentioned, X11 used to run on really old resource-constrained systems. Nothing about it precludes using it for embedded automotive applications. A tiny MCU could manage it. The MCUs used for current automotive stuff are powerful enough to run Linux with Vulkan for crying out loud.

Though I think for many of these embedded applications both X11 and Wayland are overkill when EGL direct works just fine. A full windowing system is massive overkill.

Why? X originally ran on machines far less powerful than even the shittiest automotive head units around today.

Because the problem isn't with X, it's that all the toolkits people want to use were written basically to use X as a glorified framebuffer. Wayland is a reorienting of the underlying stack to accomodate this. You could absolutely make an automotive stack with something like X and Motif, but nobody in the industry really wants to use those tools.

Nokia n900 had a touch screen smartphone UI based on gtk with X, with a 600mhz arm core and 256mb ram. I had one. It was pretty good.

I turned my N810 on recently and played a bit, so I can compare it directly to modern devices. "Pretty good" is a big understatement.

Most embedded graphical Linux applications don't use X (X Windows System), instead they use framebuffer directly or any library such as Qt Widgets or QtQuick/Qml that draws on top of the framebuffer device file. So, there is no need for developing a new Window system that can work on both Desktop or embedded systems.

Back in the day, I used to run XFree86 on a Pentium 150 with 64MB of RAM and an S3 Virge graphics card.

Don't tell me that X is bloated.

I ran it on a 386/25MHz, 8MB of RAM. It was much faster than Windows on the same machine.

Enlightenment was fast on that machine. The desktop switcher in the panel had old-school desk lamps pointing at the active desktop.

I miss that theme, and I can’t find any screenshots.

Before that, 8 MB was iffy, 16 MB good in the early Linux days.

Making life easier for Ford sounds like a low priority goal.

> We're at 12 years of Wayland and counting and the thing still isn't really usable outside a very narrow use-case.

Must be a wide narrow you're talking about. I've been using it as my default session across two different distros and the only problem I can recall having was strange mouse-grabbing behavior in Firefox, and I don't even think that was Wayland's fault.

I also still use Xorg and can't really think of a scenario where I'd switch.

This is the comment I wish I had made. The transition from 2 to 3 was terrible for end users, distros, and app developers. I wonder if redhat is trying to embrace/extend/extinguish because it's impossible for me to see gtk (and gnome) teams actions as anything less than overtly hostile.

Please don't. It's getting rather boring to see the baseless conspiracy theories that show up whenever an article is posted about gtk, gnome or systemd. Apparently they're trying to embrace extend extinguish their own business now?

When 1 company is responsible for the most cancerous, complicated, baroque, developer-hostile libraries? I think it's fine to ask these questions.

Would you create a new open-source desktop application using gtk4? Would you want to package and maintain systemd/pulse/etc?

Also: why are you responding to all the critical comments in the thread, and writing dismissive replies?

Please don't make these inflammatory comments either, it adds nothing to the discussion. You're in the thread of a GTK release announcement making these comments, I'm not sure what you're trying to accomplish but I doubt it's going to be constructive. I've used GTK for a few projects, it's not perfect but the conspiracy theories and aggression are unwarranted. Nobody is out to get you. At worst, as a developer you can ignore it and use Qt instead and it won't affect you.

Personally I would rather make a new toolkit, but it takes many years and many contributors to make a decent one. GUI toolkits are a complex business. Don't discount the amount of work that was already done on GTK or Qt, there are some serious lessons you can learn from those codebases.

Agreed.

Also, systemd seems similarly hostile and is also from redhat.

Wayland... does seem to be solving some real problems, but the transition hasn’t been going well either.

Reply on news.ycombinator.com