Is GTK 3 -> 4 expected to be as big a clusterfuck as 2 -> 3?
I'd really rather not go through all that again.
I'd really rather not go through all that again.
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.
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.
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.
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.
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.
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.
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.
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.
Don't tell me that X is bloated.
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.
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.
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?
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.
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.
Still hasn't been improved in 20 years? sad.
It's stable (unlike gtk), and truly free (unlike qt, which is also a c++ behemoth). It's utterly simple and elegant.
If you invested time and effort in writing GTK+ 2.x applications, the GTK+ developers spent zero time caring about API compatibility even for cases where it would have cost them nothing to maintain. They just had to rip it all out just for the sake of it, even when single line compatibility forwarding functions would have been entirely sufficient to avoid breakage.
This is the fundamental dichotomy with GTK+. Its developers want to hack on the toolkit itself for their own amusement and occasionally for GNOME features. They don't care about the needs of the application developers who would use their toolkit to write actual applications. God forbid it's used for its intended purpose. If you invested thousands of hours into using it, they will not bear that in mind as they rip out stuff people used for over two bloody decades in the name of "progress". Like GtkHBox. Gone. There since 1997 and used by every GTK+ application on the planet, but that's no reason to keep "old code"!
That's their choice. But other libraries like Qt do take better care of the interests of their customers and end users, and don't gratuitously break core functionality on a whim while chasing shiny new things. In the above example, the GtkHBox class is replaced by GtkBox with an "orientation" property.
Now, any sane developer would retain GtkHBox and simply implement it in terms of GtkBox with a defaulted "orientation" to horizontal. New way works. Old way works. No breakage. Everyone is happy. But they just had to rip it all out in the name of "progress". Consider how many instances of this there are in a large codebase. Hundreds to thousands in a big UI. The breakage was entirely avoidable and quite unnecessary. Maintaining the compatibility code would have been a tiny effort with a few one-liner compat functions, but ripping it out imposed huge problems upon every user of the library. "Cleanliness" needs to be traded off against "breaking end users", but they have the scale dialled all the way to one side, which is spectacularly unhelpful and inconsiderate.
That's just one class and one example. You could write a book enumerating all of the other instances. It's that bad.
No one who looks at this rationally in 2020 should be choosing GTK+ for a new project. You know in advance it will end in tears and frustration, as all of the value you created will be destroyed on a whim by developers who should know better, but go ahead and break everything anyway just because they can. That's their choice. But it's our choice to not get sucked into the bizarre world where this kind of software maintenance is considered in any way acceptable or justifiable. Seriously. These people are on another planet. What project intentionally gives the finger to all of their developer base? A really messed up one with nonsensical priorities.
Sorry if this comes over badly. If you can't tell, I've got a bit of pent-up frustration after spending far too many hours of my life trying to work around GTK+, submit patches which are ignored, and try to develop applications in spite of GTK+, not because of it. I should have just used Qt from the start.
I'm sorry, I understand your frustration but to me this is a terrible example and kind of makes the rest of your post look like complaining about a non-issue. This is exactly how it's already implemented in GTK 3. GtkHBox was deprecated there and slated for eventual removal, then it got removed in GTK 4 because the whole point of it is an API break and removal of deprecated functions. If this bothers you, you can keep using GTK 3 which is now considered feature-complete. The situation with GTK 2 was the same, you could keep on using it if you didn't want to bother updating your application.
"You can carry on using the old version" is a real cop-out which does not address the substance of the complaint in any way whatsoever.
Yes, I know it's being removed in GTK+4. You didn't have to remove it. You chose to. And to hell with the consequences. You could have kept it pretty much indefinitely with near zero maintenance overhead if you cared about compatibility and the extent to which that core functionality was used.
I am always surprised at how much time gets wasted on trivia, and yet a simple maintenance issue like this is too difficult despite requiring much less effort.
The GTK+ removals are akin to removing "strlen()" from the C library because a better "strlengh()" was added in the meantime. Compatibility matters. And well-maintained projects balance that with the addition of new features.
It cannot be overstated just how terrible compatibility breaks are. C is nearly 50 years old, and all of its standard functions are thoroughly entrenched, despite their numerous known defects. It took long enough to eliminate gets(), and that was broken from inception.
In almost all cases, removal is not the best solution. Supplementing with a safer or better alternative to supersede the original, by all means. But deliberate breakage causes nothing but pain all around.
In the case of GTK+, it's nearly 25 years old. These is a legacy of thousands of applications, large and small, which have invested hundreds of thousands of developer-hours in it. Obsoleting things might save the GTK+ developers a little extra effort (though I doubt this), but it imposes several orders of magnitude more work upon the worldwise developer base tied to GTK+, which could be avoided entirely without holding back progress.
Now if someone wanted to make a shim library that had the old APIs, that might be doable.
Removing an unused and long-deprecated interface is low impact. Removing a widely-used interface is very high impact.
When you have an interface that is nearly 25 years old and a staple part of every GTK+ application in existence... that's a very high impact change. I'm unsure how the GTK+ developers rationalised that one. But I am completely certain they made the wrong call there. It's too disruptive. I don't think it should have ever been dropped, or considered for dropping. Deprecated, yes. But not dropped.
I'm coming from the perspective of an end-user of GTK+: an application developer. Though I have historically also contributed bits upstream. I moved away from using GTK+ several years back at this point, precisely because the upstream maintenance practices were too much of an ongoing imposition, along with all the other criticisms one can make of it. GTK+ might be "free", but the cost of using it is very, very high.
This is a complete cop-out. It's maintained by several RedHat employees as part of their duties, and a handful of volunteers.
Every software project on the planet, including commercial ones, is maintained with limited resources. The amount of development and maintenance which is possible is constrained by the available developer hours, and work is budgeted based on that.
The cost/benefit of maintaining the compatibility code is so low that it's not even worth the effort to remove it. The time taken to drop it was likely on a par with the time to retain it. It was already written. But the cost imposed on all their userbase after removing it is absolutely huge. And it means that an application can't target old and new versions due to the break. That wreaks havoc with support lifetimes and imposes thousands of developer-hours of effort for porting. Lots of effort... just to get back to where you were. Unjustifiable.
I could understand if there was a huge benefit to be gained. But there isn't. And when you look at what they do spend their time on, so much is wasted on other activities that justifying its removal based upon developer resources wears a little thin. It's a weak justification which ultimately boils down to just wanting to, and completely ignoring the actual users of the library.
According to https://developer.gnome.org/gtk3/stable/gtk-migrating-3-x-to..., the changes were pretty minor.
This was apparently a part of a deliberate strategy around GNOME branding. The GNOME developers wanted all GTK apps to have one consistent look-and-feel, they wanted people to associate this look with GNOME, and they wanted people to start thinking of GTK apps as "GNOME Apps."
More recently, they crippled existing functionality for server side-window decorations in Wayland (which literally every other toolkit supports), because GNOME decided to use exclusively client-side decorations. They vetoed all of the reasonable seeming workaround proposals, essentially telling developers to either use GNOME's decorations or to manually draw the close/maximize/minimize buttons.
Honestly, all of the crap that systemd gets should be redirected towards GTK/GNOME. I've never seen a group of developers act in such bad faith.
Themers were warned, that the styling engine was under heavy rework. Gtk people could either wait few years until it's done and be stuck with Gtk2 meanwhile, or go out with Gtk3, which has relatively stable public API and internal API under rework. It's no brainer to take the same way they took. They also communicated this, so anyone who ignored their advice has no basis to complain. They were told exactly what is going to happen, and that they will either have to keep up, or not do it yet.
Switch to client-side decorations was also done for a very good reason. There's a post by Rasterman (author of the Enlightenment WM) on reddit, where he details it why - and he is not even associated with Gnome. Windows and Mac also do client-side decorations, you just cannot see it, because clients cannot connect directly to the compositors, they have to use the client side libraries that handle that. Which is exactly what Gtk does.
> API changes every minor release.
vetinari:
> the changes were pretty minor.
Was this pun intended? ;-)