5 ms·
The GTK 4 transition is totally unnecessary. Any new functionality needed can be incorporated into the existing API in a backwards-compatible manner. Major vers
by quotemstr 6y ago
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.
- war1025 6y ago> 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.
- quotemstr 6y ago> 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.
- fmntf 6y agoWhile 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).
- quotemstr 6y agoWhy? X originally ran on machines far less powerful than even the shittiest automotive head units around today.
- stonogo 6y agoBecause 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.
- rleigh 6y agoAs 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.
- moonchild 6y agoX 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.
- quotemstr 6y ago> 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.
- ATsch 6y agoYet 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.
- dilandau 6y agoThis 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.
- hedora 6y agoAgreed. 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.
- cycloptic 6y agoPlease 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?
- dilandau 6y agoWhen 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?
- cycloptic 6y agoPlease 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.