More Planning Details For GTK4 & Beyond

[boxie]

This is a problem why? It's exactly the appropriate course of action for anyone who maintains a popular dependency but also wants to do significant new development.

Somewhat. if we look at the kernel and their "Don't Break User Space" mantra we see a completely different side of the coin.

There are many things that can be done to stop a constant churn in ABI breakage, "Not working on it anymore" is just one

[Hamsterkill]

Will this new expected fragmentation lead to an increase in resource usage due to having potentially several different versions of GTK loaded for different applications?

[Stoatally]

My comment is still "awaiting moderation", what a surprise.

[oleid]

Somewhat. if we look at the kernel and their "Don't Break User Space" mantra we see a completely different side of the coin.

There are many things that can be done to stop a constant churn in ABI breakage, "Not working on it anymore" is just one

To be fair : procfs and sysfs entries change all the time. I don't know how often I had to adapt scripts.

[Luke]

I wonder how many posts above are from people who actually develop with GTK+3. I've been developing with GTK+2 since about 15 years ago, and with GTK+3 since about 3 years ago, and I've *never* *EVER* had issues with API stability. I've written 'form' and 'datasheet' classes using both GTK+2 and GTK+3, and written a bunch of database-centric apps, including an ETL framework with a nice GTK+3 GUI. I use quite a bit of the functionality available, and create custom cell renderers in the datasheet class.

What I *think* people are whinging about is the theming subsystem, which admittedly is changing quite rapidly. But theming is not a core part of GTK+3, and not a part of the "API". Maybe someone would like to share some examples of API changes that they've actually encountered?

Try the huge mess that GTK 3.21.3 made out of the Nemo and Caja desktop icon. I spend more than a month hacking code to fix this in Caja until a Nemo dev tracked down the old commit that made Nautilus work to between Nautilus 3.7.90 and 3.7.91. From there I was able to find the exact change needed, but to use it required porting all the Nemo/Nautilus transparent desktop code to caja, and it worked only in the composited case. Finally a Nautilus dev wrote code to draw the background in non-composited fallback sessions for nautilus-desktop, and I ported that to caja with good results. Still, we now have three different build cases for Caja: GTK2, GTK 3.20 and earlier, and GTK 3.21 or later.