3 ms·

> 2. Applications that have been linked for 4.2 on a system with 4.2 dev files installed will still run when the system gtk4 is 4.4. But you're not allowed to b

> 2. Applications that have been linked for 4.2 on a system with 4.2 dev files installed will still run when the system gtk4 is 4.4. But you're not allowed to build a 4.2 app anymore once 4.4 is on the system. This means, the 4.2 .so can exist in parallel but not the development files. Those are allowed to exist for only one gtk4 release. The point here is that all of these would link against something like "gtk-4-unstable.pc" which makes things easy for distributions to know what needs to be recompiled when they bump dependencies. So while it semantically is the case, I don't think it is as big of a deal as you are claiming. > Even though Gtk3 is still riddled with regressions compared to Gtk2 Gtk 2 hasn't changed in over 5 years. So I'm not sure it's suitable to compare against anything. > and there's no stable theme interface, and for example the Raleigh theme engine completely broke in 3.20, the GNOME devs seem to have decided to take it to the next level. The stable theme API landed in 3.20. That is a first time in my nearly 18 years of working with GTK. While the Raleigh didn't "completely break" as you say in 3.20, it hasn't been the "default" GTK theme for quite some time. > Yes, gtk2 has limitations, but there was ABI and API stability on all layers. I worked on one of the largest gtk2 applications shipped to date (the VMware Linux product line) so I have a little background on the topic. I also happen to be an upstream GTK developer now since I left VMware 5 years ago. And, quite frankly, this statement is incorrect. Plenty parts of GTK 2 were unstable during it's lifetime. In particular theming and gtkrc bits. I've written enough workarounds during the lifetime of gtk2 products to know. That is simply the reality when a piece of software tries to remain ABI stable for over a decade. It's really, really, really hard work (and as this post shows, almost completely thankless). The only reason gtk2 is stable today, is because it's generally not touched (except for very specific bug fixes). You'll see gtk3 be considered stable in the near future, but with a longer lifetime of bug fixes than gtk2 has gotten. Some of us are arguing for in 6 months, some for a year'ish. Meanwhile we will develop and stabilize gtk4 to land in the next series of long lifetime releases. We haven't hashed out all the details yet, but that could mean that if you subscribe to our 6 month release cycle, you might depend on say "gtk-4-unstable.pc". Where as, once we start on gtk 5, you can depend on "gtk-4.pc" and everything is guaranteed stable going forward. Those on the GTK release cycle will then consider moving to "gtk-5-unstable.pc". By moving our major numbers sooner, it's very clear that the major version you are on is no longer game for major changes. I wish we had a butter way to deal with what we call the numbers (4.6 being 'stable' for example), but semantic versioning here isn't really sufficient (nor simply soname versioning alone). We couldn't really come up with a better naming system than to say something like "4.6 is considered stable". This is a complex problem because we can either require everyone to bump their pkg-config dependencies again once they know they are stable, or not. We discussed doing something like 4 stable and 5 development, 6 stable, etc but ultimate decided against (as much as a half day decision can be) due to the churn it would take maintainers to update build system.s This is mostly made more difficult because of distributions. They often deal with packages that are written and then stagnate for a couple of years and would like them to keep working (Debian Testing → Stable for example). We've only discussed this for half of day-one of our current hackfest, so of course, if you have input, this would be a great time to join #gtk+ and make your voice heard. Many of us are here in Toronto in person, but we are certainly still all on IRC listening to users there. > Had Gtk3 only added Wayland and HiDPI support, and kept API stability for the most part, we wouldn't find ourselves in this unfortunate situations. If only we thought of it! Sorry for the snark, but your comment really trivializes the amount of work it goes into such features. It is really hard to have a reasonable discussion unless you are willing to sit down and look over the last 5 years of development and how each incremental feature plays a part in building a modern toolkit. We want to do much more modern things (like GL/vulkan rendering for example), and the recent half-decade has shown that is pretty much impossible for us to do without applications willing to test how well things work. That results in the natural feedback loop of improving things. Now, having both developers that want to write code and largely ignore it for 5-10 years is a different set of developers than those that are willing to stay up to date with the toolkit and test features as we add them. They are both completely valid desires of developers. We are stuck trying to satisfy both, which was not obvious when we started. When GTK3 started we thought it was going to be a "break everything while we figure out what GTK 4 will look like". As you can imagine (especially with hindsight), easier said than done. Each incremental change that has happened from 3.0 to 3.20 is monumental in turning a toolkit that was state of the art for 1998 into a toolkit that is state of the art for 2016. I'm not going to rehash the gigantic list of all those features, as people have done that elsewhere already today. We still aren't where we want to go, but each change we've introduced has been a step in the progression to get there.

cm3 10y ago
> Plenty parts of GTK 2 were unstable during it's lifetime. I've written a Raleigh theme more than 12 years ago, and that one still works as it did back then. I believe you when you say not all parts of Gtk2 were stable and some stuff was surely evolving, but the overall I've seen no regression in Gtk2 as I did in Gtk3. That said, if Gtk3 has only been considered stable since 3.20, then more appropriate versioning/communication might have been useful, but I doubt that's what you're saying. Also, I know I have too little domain knowledge to judge what it takes to support HiDPI and Wayland, but what I do object is focusing on too many things for a major release. What works better are time based releases where, if one feature branch misses the release, it'll arrive in a later version. Full rewrite efforts seldom work out. You said Raleigh should work in 3.20, I just tried to use it as the 3.20 theme again and it's still borked compared to 3.18, but it's unsurprising if it's not the default and probably untested. But what's more important is that Gtk2's Raleigh looks really nice, whereas 3.20's Raleigh looks like it's deliberately made to look worse, which is hard to understand, given that the drawing code is supposed to be 99% unchanged, if I look at Gtk2 to Gtk3 porting guides.
- audidude 10y ago
  > That said, if Gtk3 has only been considered stable since 3.20, then more appropriate versioning/communication might have been useful, but I doubt that's what you're saying. The theming API is what I was regarding as stable come 3.20. (CSS elements are finally documented, for example). And you are right, we could have done a better job of communicating it. It was obvious to those of us who work with GTK every day, (and theming has been unstable since gtk2 was released as it required C code), but it wasn't stated in large block print anywhere. We could have done better. To help with this we started, a few weeks ago, a new GTK blog to help people stay up to date. (blog.gtk.org) > Also, I know I have too little domain knowledge to judge what it takes to support HiDPI and Wayland, but what do object is focusing on too many things for a major release. What works better are time based releases where, if one feature branch misses the time window, it'll arrive in a later point release. Full rewrite kinda efforts seldom work out. Gtk3 has been large parts of rewrites done in short 6 month increments. That said, writing things like a full CSS 3 implementation that themers asked for is no small task. And making a modern toolkit that ships in 5 years does not do Free Software a service if it's too late to be useful. We've been trying to strike the right balance, but it takes developers testing things during the development cycle to really make that possible. Unfortunately, GNOME is pretty much the only project doing thate. > Finally, I just tried to use Raleigh as the 3.20 theme again and it's still totally borked compared to 3.18, but it's unsurprising if it's not the default. We should probably remove it from the list, to be honest. Adwaita "is the GTK theme", not Raleigh. I can add this to tomorrows topics at the hackfest. > But what's more important is that Gtk2's Raleigh looks really nice, whereas 3.20's Raleigh looks like it's deliberately made to look worse, which is hard to understand, given that the drawing code is supposed to be 99% unchanged, if I look at Gtk2 to Gtk3 porting guides. The drawing model of gtk2 and gtk3 are completely different. The themes are CSS now so the Raleigh theme, at minimum, has been ported from C code to CSS.

cm3 10y ago

> Plenty parts of GTK 2 were unstable during it's lifetime. I've written a Raleigh theme more than 12 years ago, and that one still works as it did back then. I believe you when you say not all parts of Gtk2 were stable and some stuff was surely evolving, but the overall I've seen no regression in Gtk2 as I did in Gtk3. That said, if Gtk3 has only been considered stable since 3.20, then more appropriate versioning/communication might have been useful, but I doubt that's what you're saying. Also, I know I have too little domain knowledge to judge what it takes to support HiDPI and Wayland, but what I do object is focusing on too many things for a major release. What works better are time based releases where, if one feature branch misses the release, it'll arrive in a later version. Full rewrite efforts seldom work out. You said Raleigh should work in 3.20, I just tried to use it as the 3.20 theme again and it's still borked compared to 3.18, but it's unsurprising if it's not the default and probably untested. But what's more important is that Gtk2's Raleigh looks really nice, whereas 3.20's Raleigh looks like it's deliberately made to look worse, which is hard to understand, given that the drawing code is supposed to be 99% unchanged, if I look at Gtk2 to Gtk3 porting guides.

audidude 10y ago
> That said, if Gtk3 has only been considered stable since 3.20, then more appropriate versioning/communication might have been useful, but I doubt that's what you're saying. The theming API is what I was regarding as stable come 3.20. (CSS elements are finally documented, for example). And you are right, we could have done a better job of communicating it. It was obvious to those of us who work with GTK every day, (and theming has been unstable since gtk2 was released as it required C code), but it wasn't stated in large block print anywhere. We could have done better. To help with this we started, a few weeks ago, a new GTK blog to help people stay up to date. (blog.gtk.org) > Also, I know I have too little domain knowledge to judge what it takes to support HiDPI and Wayland, but what do object is focusing on too many things for a major release. What works better are time based releases where, if one feature branch misses the time window, it'll arrive in a later point release. Full rewrite kinda efforts seldom work out. Gtk3 has been large parts of rewrites done in short 6 month increments. That said, writing things like a full CSS 3 implementation that themers asked for is no small task. And making a modern toolkit that ships in 5 years does not do Free Software a service if it's too late to be useful. We've been trying to strike the right balance, but it takes developers testing things during the development cycle to really make that possible. Unfortunately, GNOME is pretty much the only project doing thate. > Finally, I just tried to use Raleigh as the 3.20 theme again and it's still totally borked compared to 3.18, but it's unsurprising if it's not the default. We should probably remove it from the list, to be honest. Adwaita "is the GTK theme", not Raleigh. I can add this to tomorrows topics at the hackfest. > But what's more important is that Gtk2's Raleigh looks really nice, whereas 3.20's Raleigh looks like it's deliberately made to look worse, which is hard to understand, given that the drawing code is supposed to be 99% unchanged, if I look at Gtk2 to Gtk3 porting guides. The drawing model of gtk2 and gtk3 are completely different. The themes are CSS now so the Raleigh theme, at minimum, has been ported from C code to CSS.