deprecated gtk3 code in non-GNOME apps
Dear CRUX port maintainers, as I shared in #crux-devel earlier today, the recent update to adwaita-icon-theme dropped many of the stock icons. A number of gtk3 apps in our port collections still try to load these stock icons using deprecated code (`grep -n ^GDK_DEPRECATED /usr/include/gtk-3.0/gtk/*.h` will help locate some of these legacy functions). Also affected is at least one of the ports in /usr/ports/opt (geeqie). There's already an issue on the gtk gitlab (https://gitlab.gnome.org/GNOME/gtk/-/issues/4790), so perhaps a fix will soon be available from upstream. In the meantime, I've been trying without much success to patch the problematic code in my affected ports using basic sed substitutions. But even after replacing these function calls with the newer (post-3.10) syntax, I still got a Gtk-WARNING about failure to locate the requested stock icons. I think it's not enough to change the function calls superficially, because the icons themselves are not locatable using the same const char arguments as before. A port maintainer would have to write a dictionary to help "carry out the relevant name conversions", which is less viable than just pushing the issue upstream. If anyone else is maintaining ports affected by the icon theme upgrade, what would you suggest as an interim measure (until the issue is addressed upstream)? Leave a README in the port tree warning users about a degraded UI unless adwaita-icon-theme is reverted to its previous version? Post a new issue with the developers of our affected ports suggesting that legacy icon-loading code be replaced by its GTK3-3.24.10+ counterpart? In light of the last post in the XFCE mailing list thread shared by dlcusa (http://dlcusa.net/CRUX/XFCE_Wayland.mbox), I worry that by pursuing the latter option we dodge the issue of recruiting caretakers for an abandoned GTK3 branch, as the GTK project focuses more of its effort on version 4 and GNOME-specific apps. It would seem less wasteful of effort to insert the fix directly into the gtk codebase (in the manner suggested by Rich's response to Andrzej in the XFCE thread, or by ChrisVine in the gtk gitlab) than to distribute among many app developers the task of chasing a moving target (i.e., the set of functions not yet deprecated by the current stable release of gtk3). But aggregate amount of developer effort is not the only relevant consideration, so I'm open to hearing counterarguments that might persuade me to file bug reports with the authors of my affected ports. Thanks for your thoughts. -- John
Hi John, On 28.03.2022 14:49, John McQuah wrote:
There's already an issue on the gtk gitlab (https://gitlab.gnome.org/GNOME/gtk/-/issues/4790), so perhaps a fix will soon be available from upstream.
[1] should fix your issue. In short: thanks for your thoughts. I see the problem rather with geeqie and the likes that would not update their code in time. My stance is pretty simple: if upstream doesn't keep working with current versions of system libraries I usually just look for a modern alternative. I don't hold any sentimentals for old software on a modern workstation setup. Just for the record: I installed geeqie to check on the issue myself and had all icons working because I do use another gtk theme [2]. Thats probably why I didn't experience the problem in the first place with the few gtk3 apps I use. Best regards, Tim P.S.: Resent because I forgot to CC to the mailing list, sorry ;-) [1] https://crux.nu/gitweb/?p=ports/opt.git;a=commit;h=56ea13e7f3ac7db37b8e2fb25... [2] https://github.com/adapta-project/adapta-gtk-theme
Hi Tim, I can confirm that the gtk3 version bump fixes the issue. Thanks for the update, and for the recommendation to try a new gtk theme. With responsibility for maintaining thousands of CRUX ports, it's understandable that you prefer not to waste time on patching the ports that haven't kept up with the system libraries. In this case a fix was quickly posted to the system library itself, but some libraries might not be so accommodating. For those cases, dropping the old software in favor of a modern alternative is a simple resolution to the breakage that would otherwise persist in the port tree. But by not taking the opportunity to provide feedback to upstream developers, we leave them completely unaware that their user base extends into the CRUX community. To quote the Japanese proverb, "the protruding nail gets hammered." The upstream github sites might be filled with bug reports from users on Mac OS X or Windows, with hardly a peep from the CRUX users who silently moved on to an alternative at the first sign of outdated code. Due to our silence (and to their remoteness from the development of the system library they depend on), the upstream project has no idea that the GUI they wrote prior to gtk 3.10 is in need of a rewrite, and they focus their attention on the internals of the app rather than its GUI. I'm not advocating holding sentimentals for old software, but instead doing our part to improve the software we once saw fit to include in our repositories. Dropping a port at the first sign of trouble is too drastic a response, if the upstream github site is active and responsive to constructive feedback from users on other platforms. -- John
If you feel that strongly about it maybe you could file a report on it instead of laying a guilt trip on someone who volunteers there time and is already working hard for open source. Regards, Daryl Fonseca-Holt Apr. 1, 2022 07:13:52 John McQuah <jmcquah@disroot.org>:
Hi Tim,
I can confirm that the gtk3 version bump fixes the issue. Thanks for the update, and for the recommendation to try a new gtk theme.
With responsibility for maintaining thousands of CRUX ports, it's understandable that you prefer not to waste time on patching the ports that haven't kept up with the system libraries. In this case a fix was quickly posted to the system library itself, but some libraries might not be so accommodating. For those cases, dropping the old software in favor of a modern alternative is a simple resolution to the breakage that would otherwise persist in the port tree.
But by not taking the opportunity to provide feedback to upstream developers, we leave them completely unaware that their user base extends into the CRUX community. To quote the Japanese proverb, "the protruding nail gets hammered." The upstream github sites might be filled with bug reports from users on Mac OS X or Windows, with hardly a peep from the CRUX users who silently moved on to an alternative at the first sign of outdated code. Due to our silence (and to their remoteness from the development of the system library they depend on), the upstream project has no idea that the GUI they wrote prior to gtk 3.10 is in need of a rewrite, and they focus their attention on the internals of the app rather than its GUI.
I'm not advocating holding sentimentals for old software, but instead doing our part to improve the software we once saw fit to include in our repositories. Dropping a port at the first sign of trouble is too drastic a response, if the upstream github site is active and responsive to constructive feedback from users on other platforms.
-- John _______________________________________________ crux-contrib mailing list crux-contrib@lists.crux.nu https://lists.crux.nu/mailman/listinfo/crux-contrib
Hi John, On 01.04.2022 08:11, John McQuah wrote:
I can confirm that the gtk3 version bump fixes the issue. Thanks for the update, and for the recommendation to try a new gtk theme.
Thank you.
With responsibility for maintaining thousands of CRUX ports, it's understandable that you prefer not to waste time on patching the ports that haven't kept up with the system libraries. In this case a fix was quickly posted to the system library itself, but some libraries might not be so accommodating. For those cases, dropping the old software in favor of a modern alternative is a simple resolution to the breakage that would otherwise persist in the port tree.
I don't get your point here. You explained a problem that at least I was unaware off and provided the legwork by posting the upstream issue about it. I followed up on it, because at the time of your posting there has been no comment on it yet. The next day however, this one commit was mentioned to provide at least half of the fix, so at that point, I already prepared the patch commit for it. What exactly else do you expect me to do?
But by not taking the opportunity to provide feedback to upstream developers, we leave them completely unaware that their user base extends into the CRUX community. To quote the Japanese proverb, "the protruding nail gets hammered." The upstream github sites might be filled with bug reports from users on Mac OS X or Windows, with hardly a peep from the CRUX users who silently moved on to an alternative at the first sign of outdated code. Due to our silence (and to their remoteness from the development of the system library they depend on), the upstream project has no idea that the GUI they wrote prior to gtk 3.10 is in need of a rewrite, and they focus their attention on the internals of the app rather than its GUI.
I'm not advocating holding sentimentals for old software, but instead doing our part to improve the software we once saw fit to include in our repositories. Dropping a port at the first sign of trouble is too drastic a response, if the upstream github site is active and responsive to constructive feedback from users on other platforms.
John, with all due respect, I encourage you to use your voice and make it heard. I use mine wherever I feel I need to. Have a great weekend, Tim
Hi Tim, Thanks for the follow-up. I'm sorry if I gave the impression that more was expected beyond the version bump you already committed. Making my voice heard (with the developers of the ports I maintain) was indeed the action I sought endorsement for, when writing to this list. But at the time I didn't have enough evidence that the problem was really with that app, rather than with adwaita-icon-theme in its relaxed adherence to freedesktop standards, or with gtk3. I hoped that by reaching out to the contrib maintainers, I might get a better sense of which upstream project(s) should receive the bug report. The legwork you gave me credit for, by lucky chance happened to reveal the pivotal bug report, so a satisfactory resolution was found within a day. But if other crux-contrib subscribers had responded with reports of similar breakage after the adwaita-icon-theme update, and subsequent fixes that were made in the apps themselves (not in the system library), then I would have felt more confident filing bug reports with projects outside the GNOME umbrella. -- John
participants (3)
-
John McQuah -
tbier＠posteo.de -
wyatt＠prairieturtle.ca