GNOME Bugzilla – Bug 652044
uses deprecated APIs
Last modified: 2018-07-15 08:52:48 UTC
Created attachment 189389 [details] [review] initial attempt at building with gtkmm 2.24 without deprecated APIs GParted needs to be ported away from deprecated APIs, as the first step to getting it working on GTK 3. I've made a start at doing this. The attached patch builds and minimally runs; however, I've clearly done something wrong with the Cairo port, as the visual disk area is blank. There may well be other run-time problems. However, since I've run out of time for working on this at the moment, I thought I might as well attach this so that perhaps somebody else can use it as the basis for further work. I used the MM_ARG_ENABLE_WARNINGS Autoconf macro from mm-common as an easy way to get './configure --enable-warnings=fatal'. I needed to add -Wno-unused-result and -Wno-unused-parameter to src/Makefile.am to work around some GCC warnings I didn't want to deal with immediately; since there aren't too many of those, perhaps they can be fixed later and those extra -W options removed.
Thanks Colin for reporting this problem and working towards a solution. Is there a GNU/Linux distribution available that you would recommend for testing purposes so that I can work through the GTK 3 issues?
You can clean the deprecation warnings on any distribution using the gtk2 version, the gtk3 bindings are available on most of the recent distributions as well (or at least on fedora15, debian unstable, and ubuntu oneiric)
Thank you Sebastien for this additional information. Recently I found the following relevant link which should also help me with this task: Porting from gtkmm-2.4 to gtkmm-3.0 http://live.gnome.org/gtkmm/PortingToGtkmm3
(In reply to comment #0) > GParted needs to be ported away from deprecated APIs, as the first step to > getting it working on GTK 3. I've made a start at doing this. The attached > patch builds and minimally runs; however, I've clearly done something wrong > with the Cairo port, as the visual disk area is blank. Thanks again Colin for providing your initial attempt code. I have used it as a baseline, and I too have not been able to get the cairo code to work. While trying to get to the root of the problem, I tried compiling the following cairomm example: Example Application: Creating a Clock with Cairo http://developer.gnome.org/gtkmm-tutorial/3.0/sec-drawing-clock-example.html.en This example works well in gtkmm-3.0, and it compiles in gtkmm-2.4 but does not display any graphics. Hence I think the back port of some of the cairo stuff is not fully operational. In going forward I plan to use #ifdef's to check for gtkmm-3.0 or gtkmm-2.4 so that the GParted code will compile under both gnome 3.0 and gnome 2.x.
While working on this task, I have run into another stumbling block. Hopefully someone can offer me a tip on how to overcome this obstacle. The obstacle is a crash when running GParted with the git.diff applied (provided by Colin). To encounter the crash, start GParted, select unallocated space, and then choose to create a new partition. The problem appears to be with the set_sensitive method call on the comboboxtext widget in the method Dialog_Partition_New::Dialog_Partition_New(). For example: std::vector<Gtk::CellRenderer*> cells = combo_type .get_cells(); <snip> cells[ 1 ] ->set_sensitive( false ); <---- Crash location The old code with the optionmenu widget does not exhibit this problem. Any advice on how to resolve this problem would be greatly appreciated.
Created attachment 205132 [details] [review] Work in progress to further initial attempt to avoid deprecated APIs Attached is a patch that is a work in progress. This patch is not ready to be committed to the gnome git master branch. For example the patch still segfaults when creating a new partition. This patch has been uploaded in case anyone else has a chance to further investigate the segfault problem. At the moment one work-around I can think of is to change the Partition Type drop down list into a set of radio buttons. To apply the patch (removing the commit status) use: git apply 0001-Work-in-progress-to-address-bug-652044-uses-deprecat.patch To apply the patch with commit status use: git am -3 0001-Work-in-progress-to-address-bug-652044-uses-deprecat.patch
I am working on this patch again. At the moment I see three items that still must be addressed: a) Fix the segmentation fault that occurs when creating a new partition. NOTE: To encounter the crash, start GParted, select unallocated space, and then choose to create a new partition. The problem seems to be an inability to set the partition type drop down list items inactive. To work around this problem I plan to only add only valid partition types to the list. b) Address the cairo graphics Gnome 3 back ported stuff not working. The problem is that when using the back ported cairo graphics stuff, the graphics are not displayed. To work around this problem I plan to use configure options to only use the cairo graphics stuff when configured and compiled with Gnome 3 libraries. c) Comment out the MM_ARG_ENABLE_WARNINGS stanza used for testing. This one is easy, but I will leave it to the end so that it is easier to continue testing. If anyone has any comments or advice, please feel free to add to this bug report.
Well I have been able to work around the problem listed in item (a) above. However, this led me to another similar challenge. Namely the File system drop down menu previously also displayed inactive entries (e.g., file systems that could not be created because the tools are missing). I plan to investigate replacing the OPTIONMENU method with the higher up COMBOBOX method instead of COMBOBOXTEXT. Hopefully this supports inactive (i.e., non-selectable) entries.
Thanks to a response by Kjell Ahlstedt to my post on the gtkmm mailing list, I now know how to make the ComboBox method work. The relevant mailing list post can be found at the following link: Re: ComboBox with some entries not selectable or grayed out http://mail.gnome.org/archives/gtkmm-list/2012-February/msg00041.html A big thanks goes to Kjell Ahlstedt for showing the way over this hurdle. :-)
Created attachment 208415 [details] [review] Work in progress to further initial attempt to avoid deprecated APIs Good news, I am now one step closer to developing a proper patch set to address this bug report. This latest attachment fixes the segmentation fault that used to occur when creating a new partition. The two issues that remain to be addressed are as follows: a) Address the cairo graphics Gnome 3 back ported stuff not working. The problem is that when using the back ported cairo graphics stuff, the graphics are not displayed. To work around this problem I plan to use configure options to only use the cairo graphics stuff when configured and compiled with Gnome 3 libraries. b) Comment out the MM_ARG_ENABLE_WARNINGS stanza used for testing. This one is easy, but I will leave it to the end so that it is easier to continue testing. If anyone has any comments or advice, please feel free to add to this bug report.
Hi Curtis, it looks like so far you have been collecting all of the changes into a single massive patch. I think it would be a good idea to break it up into a series of smaller patches, and maybe set up a gparted-1.0 git branch to hold them and work towards gparted 1.0.0 there.
Also the number and complexity of #ifdefs for gtkmm 2.22 is mind numbing. I really think gparted 1.0 should drop support for < 2.22 as continuing to support such ancient versions is prohibitively expensive in terms of reducing code readability.
Hi Phillip, Your interest in enhancing GParted with the goal to have GParted compile and run under gtkmm-3.x is appreciated. Last week I tested the patch in comment #10 with Fedora 19 and the same problem remains with the cairo graphics Gnome 3 back ported stuff not working. See also comment #4. To compile I applied the patch on top of commit efb00f1ed0ca97239620222466ae093fb7bcec82 and then had to comment out the MM_ARG_ENABLE_WARNINGS macro in configure.in, which used to work on an earlier version of Ubuntu (11.04 I think?). The additional patch in this report includes my work back in early 2012 to try to add support for gtkmm-3.x. My thoughts were that since the back ported cairo graphics appear to be broken, then the only way to move forward was to go directly to gtkmm-3.x. I never did complete this work as I became busy with other stuff. Also the timing for implementing gtkmm-3.x support seemed to early. While working on these patches my development steps were: a) Compile using: ./autogen.sh && ./configure --enable-warnings=fatal b) Note the error and update the appropriate code c) Goto (a) Now onto the issues raised in comment #11 and comment #12. If I understand these correctly, the issues can be summarized as: I1) The complexity of #ifdefs for gtkmm 2.22 is mind numbing. Dropping support for gtkmm < 2.22 would reduce this complexity. I2) A single massive patch is unwieldy. Prefer to break it up into a series of smaller patches. I3) Suggest setup a gparted-1.0 git branch to hold patches and work towards gparted 1.0.0. Responses to issues follow: A1) I agree that dropping support for gtkmm < 2.22 would enable us to get rid of many #ifdefs. I assume that you chose gtkmm-2.22 because this version contains APIs back ported from gtkmm-3.0. Regarding getting rid of many #ifdefs, dropping support for gtkmm < 3.0 would enable us to get rid of most, if not a all of this complexity. Peronally I do not wish to support two different versions of GParted, or at least not for an extended period. As such we need to think about the appropriate time frame to switch from gtkmm 2.4 support to gtkmm 3.0 support. To help us with this decision I have pulled together the following information on currently supported major GNU/Linux distributions and gtkmm versions. Mike and Phillip, please feel free to update this chart if I have made mistakes. GNU/LINUX DISTRO SUPPORTED UNTIL GTKMM 2.4 GTKMM 3.X ================ =============== ============ ============ Centos 5.10+ 2017-03 2.10.9-1? N/A? Centos 6.x 2020-11 2.10.9-1? N/A? Debian 6.0 2014-05? 2.20.3-1 N/A Debian 7.0 TBA 2.24.2-1 3.4.0-3 Fedora 18 Early 2014 2.24.2-4 3.6.0-1 openSUSE 11.4 2014-06 2.24.4-1 N/A openSUSE 12.2 2014-01 2.24.2-5.1.2 3.4.0-2.1.2 Ubuntu 10.04 Server 2015-04 2.20.1-1 N/A Ubuntu 12.04 2017-04 2.24.2-1 3.2.1-1 If we drop support for gtkmm < 2.22, then GParted will not compile on the following distos: Centos 5.x and 6.x Debian 6.0 openSUSE 11.4 Ubuntu 10.04 If we drop support for gtkmm < 3.0, then GParted will not compile on the following distros: Centos 5.x and 6.x Debian 6.0 openSUSE 11.4 Ubuntu 10.04 Since these two lists are the same, I think that when we make the switch, we should go over completely to gtkmm 3.0. My thoughts are that mid-2014 might be a good time to make this switch based on the "supported until" dates. Some Questions: Q1) Should we drop support for gtkmm < 2.22 or go all the way and drop support for gtkmm < 3.0? Q2) What timeframe should we target for the switch in order to minimize the impact of switching? A2) I agree that a single massive patch is unwieldy. However, there is a challenge enabling newer APIs, yet still having the code compile. This is particularly a problem when I started working on gtkmm 3.0 support. Either all the code works with gtkmm 3.0, or it won't compile. Since we want all the code in a commit to compile, I am afraid that we will have to make due with some very large patches. If there is some way to work around this limitation, then I am all ears. :-) A3) Due to problems noted in (A2), I don't think that we'll be able to take advantage of multiple small commits. With this in mind I think that one person will have to develop a few large patches that others can review. I don't think that having these large patches in a git branch, and then having to change the same said patches in the git branch will be any more effective then simply working with patches. At least those are my thoughts. I am open to learning specific reasons why this might be a good idea. Curtis
Created attachment 256765 [details] [review] Work in progress patch to begin adding gtkmm 3.0 support Oops, forgot to include the patch of work-in-progress to add gtkmm-3.x support. Note that this patch applies on top of the previous patch in comment #10.
Just because a release is supported long term does not mean that we want to support the latest gparted on that release. Debian 6 is depreciated already for instance, so I don't see why we need to worry about gparted 1.0 running on it. Ignoring the apparent issues with the backported changes for the moment, the idea seems to be for gtk 2.22+ to support most of the required changes for the move to gtk3, so what I propose is for gparted 1.0 to work with either gtk3, or 2.22+. Hopefully gparted 1.0 should be ready in the first half of 2014. That should give us plenty of time to get it into shape, and support even somewhat old distros, just not really ancient ones. Until then, we should have a development branch working towards that goal while continuing work on the existing branch. During development any new features in current gparted would be included in the 1.0 branch by periodic rebasing. Once the 1.0 branch is working well with gtk 2.22 and 3.0, it would be released, and anyone still running a distro without 2.22+ would simply need to upgrade or stick to the older gparted. As far as keeping the code compiling while keeping the commits small, this is easily handled: it doesn't necessarily have to compile with the depreciated apis disabled. In other words, you disable the depreciated apis, fix one thing, and make a commit of the fix, minus the changes disabling the depreciated api. That way it compiles with the depreicated apis still enabled, and you can verify that the small commit did not break things with gtk2. You just can't verify that all of the changes fully fix gparted to work without the depreciated apis. I believe you can even choose to disable the depreciated apis on a module by module basis.
Having a minimum of gtkmm >= 2.22 is going to exclude the current RHEL / CentOS 6.x, which only has gtk(mm) 2.18. http://distrowatch.com/table.php?distribution=redhat While Red Hat themselves won't update GParted I think we should still keep GParted compiling on significant current distros. Another way to work could be to port to gtk 3.0 on a branch without regard for backward compatibility. Small commits much preferred. When complete cherry pick the changes back into master working out how to add the minimal #ifdefs.
Seeing as how that release is already 3 years old, I'd say that anyone wanting to bypass the distribution and build and install the latest gparted can also be bothered to install an up to date gtk library too. And keep in mind this is still another 6 months away, and at least at first, gparted 1.0 will have feature parity with the last 0.xx, so they can probably continue to run that and not miss anything until a year or so from now, when they will then be running a 4 year old distribution. I don't think we should feel bad telling someone trying to build gparted on a 4 year old distribution that they will also have to build a library. I think very few people will be in that situation, so better to put the ( really pretty small ) burden on them instead of making it somewhat harder to work on the code and more likely to have bugs that will effect everyone.
I believe that 2.18 is of 2010 vintage. RHEL / Centos 6.4 was released in early 2013 when newer versions of both gtkmm v2 and v3 were available. I wonder why RHEL / Centos have such an old version of gtk(mm)? Are they planning to not support gtk(mm) applications on the platform? On the plus side, even if RHEL / Centos do not plan to support gtk(mm), applications like GParted can still be run from live media.
While trying to answer some my own questions from comment #18 about gtkmm support in RHEL / Centos I came across the following Red Hat bug report. Bug 504903 - Question: Is there any plan to add gtkmm in RHEL5 or RHEL6? https://bugzilla.redhat.com/show_bug.cgi?id=504903 This bug has been closed as a duplicate of another bug. Unfortunately when I try to view the report (even when logged in with a RedHat bugzilla account), I see the following message: You are not authorized to access bug #509001. Can anyone else view the contents of this link? https://bugzilla.redhat.com/show_bug.cgi?id=509001
Nope... you gotta love redhat's bug tracker...
(In reply to comment #18) > I believe that 2.18 is of 2010 vintage. > > RHEL / Centos 6.4 was released in early 2013 when newer versions of both gtkmm > v2 and v3 were available. > > I wonder why RHEL / Centos have such an old version of gtk(mm)? RHEL generally don't upgrade components after the initial release, so RHEL 6 was released in Nov 2010. It was based on Fedora 12 released Nov 2009 which came with gtkmm-2.18. Sometime in 2017 when RHEL 6.10 update is released it will still come with gtkmm-2.18. It's just how Red Hat maintain binary compatibility. They patch in selected features into old code. http://en.wikipedia.org/wiki/Rhel#RHEL_6 https://access.redhat.com/site/support/policy/updates/errata/ > Are they planning to not support gtk(mm) applications on the platform? Yes gtkmm is included in RHEL. GParted is not part of the core distro but is part of EPEL (Extra Packages for Enterprise Linux). It's a really old version, 0.6.0. It might be possible to get this updated as the update policy says: Only updates that fix important bugs (say: data-corruption, security problems, really annoying bugs) go to a testing branch for a short time period and then are pushed to the stable branch http://fedoraproject.org/wiki/EPEL http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Package_maintenance_and_update_policy
Hi Mike and Phillip, Thank you for sharing your thoughts on the issues involved upgrading GParted gtkmm support. After reading your comments I have come to the following conclusions. > Q1) Should we drop support for gtkmm < 2.22 or go all the way > and drop support for gtkmm < 3.0? Currently I think that dropping support for gtkmm < 2.22 should only be an immediate stepping stone to full gtkmm 3.0 support. My primary reasons are: 1) The gtkmm 3.0 back ported cairo graphics stuff does not work. As such we would have to keep gtkmm < 2.22 code in GParted anyway. Hence we would not be able to actually have a GParted release that contains code that strictly follows 2.22 < gtkmm < 3.0. 2) We would have to prematurely drop support for a major currently supported distro, namely RHEL/Centos if we drop gtkmm < 2.22 support. I believe it is best if GParted can compile and run on as many currently supported distros as is reasonably possible. > Q2) What timeframe should we target for the switch in order to > minimize the impact of switching? My suggestion of mid-2014 for migrating off of gtkmm < 2.22 is only a suggestion at this time. I believe we should pick a date that involves the least amount of inconvenience, and also minimizes the amount of work we need to do with the GParted code. Specifically I do not think it is good use of our resources to support both gtkmm < 2.22 and gtkm >= 3.0 at the same time. At the moment the GParted code compiles and runs on both the newer distros and many older currently supported distros. At some point in time I believe that support for the gtkmm 2.x series will be dropped and that will be a hard deadline that will force an upgrade in GParted. Having said that I think we can try to time our migration off of gtkmm < 2.22 later rather than earlier. If there were a compelling reason to migrate to gtkmm 3.x earlier then we should consider this. At the current time I do not think that there are any specific new features in gtkmm 3.0 that are "must haves" for GParted. In addition, I do think we have some time before we are forced to migrate from gtkmm < 2.22. If I recall correctly, the GTK toolkit was born out of the GIMP project. From what I can tell, GIMP does not yet support GTK 3.0, though there is a branch created for this future path [1]. As such any distribution that wishes to support GIMP, will also have to support GTK 2.x. This gives me a level of comfort that support for GTK 2.x will continue at least until GIMP makes the switch to GTK 3.x. > I3) Suggest setup a gparted-1.0 git branch to hold patches and work > towards gparted 1.0.0. I value both of your opinions, and since you appear to be in agreement that a gparted 1.0.0 branch could work for preparing for an eventual move off of gtkmm < 2.22, please feel free to create the branch. Having such a branch would also be aligned with GIMP since they appear to have created a GIMP 3.0 branch for future support of GTK 3.x. Curtis [1] GIMP Roadmap http://wiki.gimp.org/index.php/Roadmap
Created attachment 257051 [details] [review] Stop using deprecated method free_colors() (v1) Hi Curtis and Phillip, Here's a small first step. Quoting the commit message: Stop using deprecated method free_colors() (#652044) Gtkmm releases 2.7.1 in July 2005 and 2.8 in September 2005 depreciated Gdk::Colormap::free_colors() and replaced it with Gdk::Colormap::free_color(). The oldest distribution currently supported is RHEL / CentOS 5.9 with gtkmm 2.10 so just unconditionally replace. ANNOUNCE: gtkmm 2.7.1 https://mail.gnome.org/archives/gnome-announce-list/2005-July/msg00025.html ANNOUNCE: gtkmm and glibmm 2.8 https://mail.gnome.org/archives/gnome-announce-list/2005-September/msg00026.html I've successfully created, resize and viewed details of a partition on CentOS 5.9. It can be applied to the master branch now and is a small step in reducing the difference to gparted-1.0. Thanks, Mike
Hi Mike and Phillip, After making one minor change to the patch in comment #23 (typo "depreciated" -> "deprecated" in comment text), I successfully tested on the following distros: debian 6 ubuntu 10.04 kubuntu 12.04 openSUSE 12.2 Because all of these distros use gtkmm > 2.8, I did not expect any problems. Since the patch in comment #23 aligns with all of our current goals (small patch, works with all of our currently supported major distros, avoids need to support two or more gtkmm versions), I have committed the patch to the master branch of the GParted git repository. The relevant git commit can be viewed at the following link: Stop using deprecated method free_colors() (#652044) https://git.gnome.org/browse/gparted/commit/?id=7f5ac07c3a5e7de3b900056122f8892f48735931 If there are any more deprecated APIs that are similar to this one, then these should be considered as well. Curtis
Created attachment 257624 [details] [review] Stop using depreciated widget alignment enumerators (v1) Hi Curtis and Phillip, This is another step in reducing the difference to gparted-1.0. It gets rid of the use of deprecated alignment enumerators Gtk::ALIGN_LEFT etc. Successfully tested on: CentOS 5.9 with gtkmm-2.10.10 Debian 6 with gtkmm-2.20.3 Fedora 14 with gtkmm-2.22.0 Fedora 19 with gtkmm-2.24.2 Thanks, Mike
Hi Mike and Phillip, The patch set in comment #25 is an interesting solution to getting rid of the widget alignment enumerators by removing them as parameters from the method Utils::mk_label(), and instead hard coding floating values for the alignments directly in the method. This works for now, and if we encounter problems in the future, we can always switch back to using the alignment enumerators in our migration to GTKMM 3.x. Successfully tested on: debian 7.0 ubuntu 10.04 LTS kubuntu 12.04 LTS ubuntu 13.04 fedora 10 (this was the oldest VM I had for fedora, tho' not supported) The patch set has been committed to the git repository. The relevant git commits can be viewed at the following links: Replace widget alignment ALIGN_TOP with ALIGN_CENTER (#652044) https://git.gnome.org/browse/gparted/commit/?id=8b57278f67b38116faa27b9a5c67c8f43539d32d Replace widget alignment ALIGN_RIGHT with ALIGN_LEFT (#652044) https://git.gnome.org/browse/gparted/commit/?id=18e2eb86187df1aaba6fadb3c51dde95d26e2b4f Stop using deprecated widget alignment enumerators (#652044) https://git.gnome.org/browse/gparted/commit/?id=be2689ad25c104e3cb97e7d5d1f7627dbb137b19 Curtis
The patches from comment #23 and comment #25 that were committed in comment #26 have been included in the GParted 0.17.0 release on December 9, 2013. Note that this bug report is still open because the above listed enhancements resolve only a portion of this report.
*** Bug 791286 has been marked as a duplicate of this bug. ***
'Just adding another concern we may have to program around if/when migration from gtkmm 2.x to 3.x is re-attempted. I've read that GTK3 has been shown to break ABI compatibility between releases. Following is one of the references I read: Are GTK+ developers destroying Linux desktop with their plans? https://fosspost.org/opinions/are-gtk-developers-destroying-linux-desktop-with-their-plans In my opinion ABI compatibility is critically important, especially to a hobby project like GParted. The instability of GTK3 makes me less than keen to attempt the migration again.
Curtis, gtk3 is now in long-term stable support since 3.22 was released in September 2016. Therefore, this is a great time to switch to gtk3. GTK4 is under active development, but I haven't found any apps using it so there's no reason to worry about it yet for gparted. The post you linked to is based on outdated information. Here's an update: https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/
Thanks Jeremy for the information. From the link in comment #30: New major versions will be released once new features have stabilised, which is expected to be roughly every 2-3 years. When bumping to a new major version deprecated API will be removed. ... We’ll also keep doing micro releases for bug fixes and security issues, for at least three years. If I understand this correctly then there is the possibility that features may be disappearing as often as every 2-3 years. For example features are marked deprecated in *major-release-version-minus-1* and then actually removed in **major-release-version**. There could be a constant flow of deprecated features with every major release. This proposal is nowhere near as stable as GTK2 has been.
Yes, but you don't HAVE to switch to GTK4 as soon as it comes out. This basically is a return to the same sane policy that they used to have of bumping the major number on incompatible changes, and not making such changes all that often. It would be really nice to get gparted moved to GTK3 finally so it can run under Wayland directly without the Xwayland compatibility server.
In order to clarify, I did not say that GParted should not move to GTK3 or Wayland compatibility. What I said is that the GTK3 ABI has not been as stable as GTK2, nor is the new proposal as stable as GTK2. As stated on the GParted Development page [1]: We try to ensure that the GParted will compile and run on the currently supported versions of many major GNU/Linux distributions (distros). Distros we often include in our testing include: Centos/RHEL, Debian, Fedora, openSUSE, and Ubuntu. [1]: https://gparted.org/development.php We welcome patches to migrate to GTK3 / Wayland.
> nor is the new proposal as stable as GTK2 I think it's clear that new major releases will not be as stable for app developers as bugfix releases to a long term support branch. ;)
By stable I mean not only does the ABI remain the same, but further the release is supported for many years. To test the stability of GTK2 I fired up the oldest Virtual Machine I have (Fedora 12 released in 2009). The current GParted 0.30.0 still compiles and runs on Fedora 12. That demonstrates the long term ABI and support stability of GTK2.
Not really Curtis; you will still be able to do that in 100 years since GTK2 is not being updated. That doesn't mean it has had 100 years of stable support.
My point is the new GTK3+ proposal states support for a minimum of 3 years. I think it is unreasonable to expect a hobby project to update to a new GUI every 3 years.
Curtis, respectfully, I think the topic here should be limited to porting gparted to gtk3. If you have concerns about gtk's planned support length, please discuss that with gtk developers. By the way, there have been no gtk2 bugfix releases since gtk 3.22's release. I think this is simply because no one cares enough to do the work. That's the same problem that will happen with future gtk releases. Unless someone is getting paid to support old gtk, it's hard for most qualified people to be interested in it.
Jememy, I raised the issue in comment #29 that GTK3 had broken the API between releases as a heads up to whoever undertakes the initiative to address this bug report. In order to support older distros the person developing the patch may need to work around this ABI break.
As long as you aren't trying to handle theming yourself, I think gtk3 probably won't cause problems for LTS distros.
This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. GParted | Port to GTK3 https://gitlab.gnome.org/GNOME/gparted/issues/7