GTK's plan to fix everything: break compatibility every 6 months
-
Meanwhile, Gtk 4.0 will not be the final stable API of what we would call “Gtk 4”. Each 6 months, the new release (Gtk 4.2, Gtk 4.4, Gtk 4.6) will break API and ABI vs. the release that came before it.
Anything to avoid just stopping work and doing some up-front design, I guess. Up-front design is for nerds!
-
In February 2003, a bunch of the outstanding bugs I'd reported against various GNOME programs over the previous couple of years were all closed as follows:
Because of the release of GNOME 2.0 and 2.2, and the lack of interest in maintainership of GNOME 1.4, the gnome-core product is being closed. If you feel your bug is still of relevance to GNOME 2, please reopen it and refile it against a more appropriate component. Thanks...
This is, I think, the most common way for my bug reports to open source software projects to ever become closed. I report bugs; they go unread for a year, sometimes two; and then (surprise!) that module is rewritten from scratch -- and the new maintainer can't be bothered to check whether his new version has actually solved any of the known problems that existed in the previous version.I'm so totally impressed at this Way New Development Paradigm. Let's call it the "Cascade of Attention-Deficit Teenagers" model, or "CADT" for short.
It hardly seems worth even having a bug system if the frequency of from-scratch rewrites always outstrips the pace of bug fixing. Why not be honest and resign yourself to the fact that version 0.8 is followed by version 0.8, which is then followed by version 0.8?
But that's what happens when there is no incentive for people to do the parts of programming that aren't fun. Fixing bugs isn't fun; going through the bug list isn't fun; but rewriting everything from scratch is fun (because "this time it will be done right", ha ha) and so that's what happens, over and over again.
-
@blakeyrat said in GTK's plan to fix everything: break compatibility every 6 months:
Why do we keep building rotten foundations?
I have a theory that they do it just to annoy you.
-
@blakeyrat holy shit that's terrible. It's like they think they're MSDN or something. Practically begging for someone with sense to fork.
-
Every two years is another year of the linux on desktop, yay!
-
Basically the entire GNOME project is now run by people being paid to work on it, and somehow these people have managed to make mobile/webtech focused version 3's of everything that suck. GNOME itself, GDM, GTK.... all horrible crap-piles that are either being forked or abandoned. Like putting the standard file/edit/help/etc menus behind a hamburger menu on a non-touch 24" desktop display????? DO NOT WANT!
ETA:
-
@pydsigner Who's paying them?
-
@pydsigner said in GTK's plan to fix everything: break compatibility every 6 months:
behind a hamburger menu on a
non-touch 24" desktop240" virtual reality displayABFY
Filed under: Annoyed Blakeyrat For You
-
@blakeyrat Largely Red Hat.
-
@blakeyrat said in GTK's plan to fix everything: break compatibility every 6 months:
@pydsigner Who's paying them?
-
@candlejack1 That's a bit different, I'm talking about people who are directly sponsored by their employers to work on GNOME. In 2010, a survey revealed that around 30% of GNOME core contributers were being paid by their employers to write 70% of the code.
-
@pydsigner and kde is still a lot better, how can it be?
-
I'm strongly in favor of breaking backward compatibility every now and then. We know it's practically impossible to design an API that people will still like in 15 years, so you might as well plan its replacement yourself. After deprecating you can just keep the old code around forever, only touching it if there are security issues.
Not every 6 months obviously. More like 6 years. Probably longer.
But from the article, it seems what they really are planning to do is: Gtk 4.0, 4.1, 4.2... will just be "development" versions that change from one to another, but when they are happy enough with them they will stabilize it and just call it "Gtk 4". Then move on to Gtk 5.0, 5.1, 5.2.... so as long as you use the latest "stabilized" version it will be OK.
Basically they have invented beta versions in an incredibly confusing way, and are doing version numbers backwards.
-
@anonymous234 and you may be sure that they are going to keep rewriting all of the core apps to use the newest versions, which is all good except that you'll only be able to use the themes that update often enough to keep up — i.e. only that ugly thing called Adwaita. However, that might be intentional: https://igurublog.wordpress.com/2012/11/05/gnome-et-al-rotting-in-threes/. (Yes I'm ticked, I liked my theme and GTK 3.20 took it away with no way to get back without downgrading FF to something with security holes.)
-
@blakeyrat Hang about, are you saying that people still deliberately choose to use GTK?!
It was shit 15 years ago (when I did some contract work developing an app using it) and it will still be shit now because the fundamental design of the toolkit was done by people who put the “pathetic numbskull” into “fucking ignorant mouth-breathing dimwits”. Software doesn't usually recover from being birthed that far up shit creek.
I keep waiting for a Certain Korean Corporation to announce that they're switching to using it for their smart TV systems.
-
@pydsigner said in GTK's plan to fix everything: break compatibility every 6 months:
. However, that might be intentional: https://igurublog.wordpress.com/2012/11/05/gnome-et-al-rotting-in-threes/. (Yes I'm ticked, I liked my theme and GTK 3.20 took it away with no way to get back without downgrading FF to something with security holes.)
Great article, deserving of its own thread.
-
@blakeyrat said in GTK's plan to fix everything: break compatibility every 6 months:
Who's paying them?
They're doing it out of sheer hatred of humanity.
-
@FrostCat said in GTK's plan to fix everything: break compatibility every 6 months:
They're doing it out of sheer hatred of humanity.
Any sufficiently boneheaded stupidity is indistinguishable from malice.
-
The linked article is pretty funny, too. "GTK's removing functionality users want because of an influx of Windows developers and their mindset."
-
@anonymous234 I would love if C++ got rid of stuff that didn't make sense for the last 10 years
-
@candlejack1 They've actually reserved
stdN
namespaces in C++17, where N is an integer. But that's just for the standard library, and they may never act on it.
-
@LB_ Fuck them, it's 50 years too late for it to improve.
-
@candlejack1 So when C++ was initially in development it was already 13 years too late to get rid of stuff from C++ that didn't make sense in the 2006-2016 time period?
-
@LB_ maybe, they adopted shit that didn't make sense from C, it's still possible I got it right
-
@error said in GTK's plan to fix everything: break compatibility every 6 months:
Fixing bugs isn't fun; going through the bug list isn't fun; but rewriting everything from scratch is fun (because "this time it will be done right", ha ha) and so that's what happens, over and over again.
Fixing bugs could be fun. If it amounts to something and if it does not look or smell like dumpster diving. Crappy code written in C, eek nope
-
@blakeyrat said in GTK's plan to fix everything: break compatibility every 6 months:
Up-front design is for nerds!
Up-front design is a good way to permanently bake in mistakes.
There's a balance to be found, but APIs that don't change for decades are... ugh.
-
I imagine a lot of people are just going to stick to 3.0
Because a broken API is no worse than an unpredictably broken API.
-
I'm having problems explaining the simple concept that you can design up-front and still be flexible...
-
@xaade
gtk_real_draw_button_ex
-
@xaade said in GTK's plan to fix everything: break compatibility every 6 months:
I'm having problems explaining the simple concept that you can design up-front and still be flexible...
Design for flexibility. Don't do all the details, do the general framework and toolkit of components that fit together in the framework. Then you can much more easily slot the components together to make your app.
In short, stop building (most) apps entirely in C or C++ and do more with scripting.
-
As far as I can tell, the GTK way to future-proof an API is:
- Hunt down any interface which looks simple and replace it with something twice as complicated.
- Explain that the new interface is actually simpler because it no longer does what you want.
- Illustrate the point with code samples which don't compile because there ain't no-one got time to remember all the new type names.
- Mark the complicated replacement as deprecated because GNOME decided not to use it.
- Take any interfaces which are still standing and change all the function prototypes without mentioning it to anyone.
- Publish the changes via some random dude's blog. There's no point having a release note, because the new interfaces are all deprecated and shouldn't be used in new code.
-
@dkf said in GTK's plan to fix everything: break compatibility every 6 months:
because the fundamental design of the toolkit was done by people who put the “pathetic numbskull” into “fucking ignorant mouth-breathing dimwits”
Care to write a @NeighborhoodButcher -style rant for people who've never used GTK?
-
@dkf said in GTK's plan to fix everything: break compatibility every 6 months:
In short, stop building (most) apps entirely in C or C++ and do more with scripting.
+1
I QML. So much better than writing your UI logic in C++.
-
http://linuxhaters.blogspot.co.uk/2008/06/how-to-write-kde-application.html
andhttp://linuxhaters.blogspot.co.uk/2008/06/how-to-write-gnome-application.html
-
@dkf said in GTK's plan to fix everything: break compatibility every 6 months:
In short, stop building (most) apps entirely in C or C++ and do more with scripting.
Isn't that what webapps are?
-
@lucas1 said in GTK's plan to fix everything: break compatibility every 6 months:
http://linuxhaters.blogspot.co.uk/2008/07/what-is-kde.html
and
http://linuxhaters.blogspot.co.uk/2008/06/how-to-write-gnome-application.html
> 2008
Yeah no.
-
@aliceif most of it is still relevant and also a bit of a joke.
-
@lucas1 said in GTK's plan to fix everything: break compatibility every 6 months:
@aliceif most of it is still relevant and also a bit of a joke.
Where is that "What is KDE" page?
-
I fucked up on the links, I failed at copy and pasting the KDE article.
-
I get a bit worried about Xfce, the desktop environment I jumped to after having GNOME 3 imposed on me unexpectedly by a careless
aptitude full-upgrade
, being based on GTK. The core components are still GTK2, but the Xfce devs have never given any hint at all of having even the slightest interest in moving to any non-GTK toolkit. Which is a shame, because GTK was
https://www.youtube.com/watch?v=jeg3ZPEm9Ns#t=17s
and is getting worse, not better.If Xfce goes down a GTK{3,4,5,6,7...} rabbit hole I'll probably jump to LXQt.
-
@LB_ No, webapps are written entirely in a scripting language.
I had that idea too, that applications should be written in a "service-oriented" way, exposing function calls to do the stuff you want, then the user interface should be created on top of that in a simpler (and standard, if possible) scripting language.
-
@aliceif said in GTK's plan to fix everything: break compatibility every 6 months:
2008
Yeah no.There were just as many delusional people in 2008 telling us how great the Lunixes were as there are now.
-
@asdf said in GTK's plan to fix everything: break compatibility every 6 months:
Care to write a @NeighborhoodButcher -style rant for people who've never used GTK?
It was a long time ago. About 15 years. The details are very hazy, and I've been happily GTK-free since then.
At that point, I was doing a short bit of internal contracting as the big project that I'd been working on for years at that point had come to an abrupt end (it failed a funding round). I was working on adapting an application written using GTK to do more complex displays and in a more flexible way. The application (gtkwave) was overall quite neat, in that it was doing waveform display as a virtual oscilloscope that read data in from some trace formats that it understood (which might've been simulation-derived, or maybe not; I forget which). It was pretty neat, and coped with gigabytes of data at a time when applications that did that were really rare and nobody had enough memory to really keep everything around at once. I was changing the code so it didn't just do simple binary signals, but also handled the floating state and the undefined state, or even could work with real-valued signals; I did it all by setting up a generalised plugin system based on shared library loading, and so on. It was a nice application.
But it used GTK, which was just horribly low-level and complicated. The pattern of use was about as complicated as working with raw X11 (nobody wants that; you're not supposed to program at that level) but with a whole ass-load of really long-winded and undocumented API calls. I was just having to examine existing code, grep the damn header files, and take a wild-assed guess to figure it all out. Decisions on what API call to use with it were essentially at the level of needing to decide how to hammer in a nail: is it the empty beer bottle or the old shoe that we should use this time? Hellish, especially by comparison with other more competent toolkits that I'd been working with previously (where you'd just say what you want drawn and the general rules for arranging all the widgets, and the toolkit would look after all the event handling and low-level drawing to make it actually happen).
It doesn't sound like it's got any better since. Because why would it? The authors probably think that being really low level is a proof of how awesome they are, as it gives them Complete Control Over All The Things, and they see that as something so inherently good that they'll never look past it. My experience is that you probably don't want that; it's typically best to just sketch the general outline and let someone else's code handle the nitty-gritty.
I might be doing them a disservice, as it was many years ago. I really doubt it though…
-
@another_sam said in GTK's plan to fix everything: break compatibility every 6 months:
Up-front design is a good way to permanently bake in mistakes.
That's why you spend more time on it, so you make fewer mistakes.
@another_sam said in GTK's plan to fix everything: break compatibility every 6 months:
There's a balance to be found, but APIs that don't change for decades are... ugh.
If an API didn't change for decades, and yet were still relevant and useful, it wouldn't be "ugh", it'd be an amazing monument to the skill of the developers who originally designed it.
Of course open source developers have no idea what the fuck they're doing. So they couldn't pull it off. But the concept's sound.
-
@blakeyrat said in GTK's plan to fix everything: break compatibility every 6 months:
If an API didn't change for decades, and yet were still relevant and useful, it wouldn't be "ugh", it'd be an amazing monument to the skill of the developers who originally designed it.
Of course open source developers have no idea what the fuck they're doing. So they couldn't pull it off. But the concept's sound.There are a few of these APIs about. They're pretty rare.
-
Ironically, I work for a company that has a monolithic C ported to C++ enterprisery, and it supports loading a dynamic list of "functions" at runtime, and dynamically calling them with a single executable. Which means its "API" is dynamic, without any scripting.
-
@xaade said in GTK's plan to fix everything: break compatibility every 6 months:
Which means its "API" is dynamic, without any scripting.
Any sufficiently advanced configuration system is indistinguishable from scripting.
-
@dkf Point being, my company figured this out decades ago.
-
@dkf said in GTK's plan to fix everything: break compatibility every 6 months:
Any sufficiently advanced configuration system is indistinguishable from
scriptingmagic.The original version of the ending fits a bit better. For me anyway.
-
@xaade said in GTK's plan to fix everything: break compatibility every 6 months:
@dkf Point being, my company figured this out decades ago.
That just means that they are overdue to fuck it up really horribly and make your working life a living hell.