5 ms·

Even though Gtk3 is still riddled with regressions compared to Gtk2, and there's no stable theme interface, and for example the Raleigh theme engine completely

by cm3 10y ago

Even though Gtk3 is still riddled with regressions compared to Gtk2, 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. That means, unless I'm reading things wrong, this is the gist: 1. API and ABI breakage twice a year 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. 3. (2) combined with (1) is a nice way to prevent adoption Now, this may sound rude, but given the state of Gtk3 after 10 major releases and the overall way devs have dealt with the community, I must say I welcome this, because it can be a nice motivator for everyone that still believed in Gtk3 to look at Qt. * Wireshark has a Qt frontend now * wxWidgets has a Qt backend now (experimental for now) * mkvtoolnix is Qt only now * the list goes on If anyone believes developers ported from Gtk2 to Qt for fun, please consider the effort it takes. Yes, gtk2 has limitations, but there was ABI and API stability on all layers. Since gtk3, the development model seems to be inspired by web applications in that breakage is frequent and stability is mostly not guaranteed. It starts with drawing regressions and extends to a theming api which is unstable and therefore could also not exist, because each theme has to exist for each major gtk3 version. 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. Since, more than a few applications have migrated to Qt. I don't like some of the things in Qt5 like the file selector, but that's a minor nuisance for avoiding gratuitous regressions. I have to use Firefox ESR because the switch to Gtk3 broke too much in the UI (in addition to general non-existence of stable Gtk3 themes).

PeCaN 10y ago
I feel like a well-executed Gtk2 fork could be very popular. I checked and MATE uses Gtk3—I thought it had forked Gtk2 along with GNOME2, but apparently not.
- audidude 10y ago
  It turns out if you want modern features you pretty much have to change everything that was done in the drawing model in gtk2.
- digi_owl 10y ago
  Because there is no need. GTK3 is basically a fork of GTK at this point. Just grab GTK2 and go. The basic problem is that most of GTK development is happening "thanks" to Gnome and Red Hat, and they are gung ho about GTK3. In essence, how the fuck do you keep going when the 800lb gorilla wants to go in a different direction?
  - deleted 10y ago
    [deleted]
  - audidude 10y ago
    GTK development is done by the people that show up to do the work and contribute patches. That happens to be, by and large, GNOME developers. The best way to affect GTK development is to either 1) show up for hackfests (like this week in Toronto), 2) join in on IRC where we plan things, 3) work on bugs, submit patches, etc I've been working on GTK for the better part of two decades, and employed by Red Hat for about 9 months. They have in no way ever influenced my contributions (I've barely ever been to an office). My contributions were just as many before my employment as they are now. My suggestion would be to join in on #gtk+ and make your voice heard this week while we plan out the next year of work (unless you are Toronto based, and then just join in person).
audidude 10y ago
> 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.
ChuckMcM 10y ago
This is why I've resorted to looking for things based on Qt rather than Gtk. I cannot fathom what the Gnome team has for their "target" or "typical" user, I'm guessing it's some sort of unholy love child between MacGyver and a Brown Motie.
- digi_owl 10y ago
  I recently learned that there is a continuation of KDE3 out there, called Trinity. Complete with a maintenance fork of Qt3. They seem to even having maintained the structuring of the KDE3 source releases, so that rolling ones own install quite straight forward. Its either that or give up on the DEs completely and adopt a WM (IceWM seems tempting).
- cm3 10y ago
  I use a window manager (or Wayland compositor) with select GUI apps and no desktop environment, so I'm not the customer of the GNOME or KDE projects. I don't have a 4k screen, so the, from my perspective, wasted vertical screen estate in Gtk3's supported and promoted style is a usability disaster for me. As I wrote in a sibling comment, I've been using the same Gtk2 theme I wrote more than 12 years ago and never had the urge to change it because the behavior and color scheme of that Gtk2 Raleigh mod suit me well. With Gtk3 I had managed to kinda imitate that despite the limited emulation in CSS of Raleigh, but in 3.20 it all blew up for me (even vanilla Raleigh).

by cm3 10y ago

PeCaN 10y ago

I feel like a well-executed Gtk2 fork could be very popular. I checked and MATE uses Gtk3—I thought it had forked Gtk2 along with GNOME2, but apparently not.

audidude 10y ago
It turns out if you want modern features you pretty much have to change everything that was done in the drawing model in gtk2.
digi_owl 10y ago
Because there is no need. GTK3 is basically a fork of GTK at this point. Just grab GTK2 and go. The basic problem is that most of GTK development is happening "thanks" to Gnome and Red Hat, and they are gung ho about GTK3. In essence, how the fuck do you keep going when the 800lb gorilla wants to go in a different direction?
- deleted 10y ago
  [deleted]
- audidude 10y ago
  GTK development is done by the people that show up to do the work and contribute patches. That happens to be, by and large, GNOME developers. The best way to affect GTK development is to either 1) show up for hackfests (like this week in Toronto), 2) join in on IRC where we plan things, 3) work on bugs, submit patches, etc I've been working on GTK for the better part of two decades, and employed by Red Hat for about 9 months. They have in no way ever influenced my contributions (I've barely ever been to an office). My contributions were just as many before my employment as they are now. My suggestion would be to join in on #gtk+ and make your voice heard this week while we plan out the next year of work (unless you are Toronto based, and then just join in person).

audidude 10y ago

> 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.

ChuckMcM 10y ago

This is why I've resorted to looking for things based on Qt rather than Gtk. I cannot fathom what the Gnome team has for their "target" or "typical" user, I'm guessing it's some sort of unholy love child between MacGyver and a Brown Motie.

digi_owl 10y ago
I recently learned that there is a continuation of KDE3 out there, called Trinity. Complete with a maintenance fork of Qt3. They seem to even having maintained the structuring of the KDE3 source releases, so that rolling ones own install quite straight forward. Its either that or give up on the DEs completely and adopt a WM (IceWM seems tempting).
cm3 10y ago
I use a window manager (or Wayland compositor) with select GUI apps and no desktop environment, so I'm not the customer of the GNOME or KDE projects. I don't have a 4k screen, so the, from my perspective, wasted vertical screen estate in Gtk3's supported and promoted style is a usability disaster for me. As I wrote in a sibling comment, I've been using the same Gtk2 theme I wrote more than 12 years ago and never had the urge to change it because the behavior and color scheme of that Gtk2 Raleigh mod suit me well. With Gtk3 I had managed to kinda imitate that despite the limited emulation in CSS of Raleigh, but in 3.20 it all blew up for me (even vanilla Raleigh).