I'm curious as to why --disable-gtk is hardcoded and no useflag is provided to build with gtk instead of qt like in 3.10? Reproducible: Always
Audacious upstream announced they're going to remove the GTK+2 code this release [1], so that explains the ebuild. Nobody @gentoo has really paid any attention to audacious for the last few years so I'll elaborate: GTK+ is already lagging behind the Qt5 GUI in feature support (none of the new plugins work on it and the last few GTK-only ones are in the process of being ported) and - more importantly - nobody's stepped up to add it to the new build system that's replaced the old Autocruft code. That's being kept on life support so they can do a win32 binary release of 4.0 without holding everything else up, but after that it's all gone for good. While I can empathise with the desire to keep using GTK+2, it's better to get it over with and rip off the bandage now. It's not like it's downgrading you to Gtk3. [1]: https://redmine.audacious-media-player.org/boards/1/topics/2436
Upstream has switched to qt5 by default and beta testing is targeting the default only. Re-adding the substantial ebuild complexity for gtk2 may be only worthwhile in case defects are uncovered in the qt5 implementation that for some reason are substantial enough that upstream can not fix your bugs in time for the final release.
(In reply to Anthony Parsons from comment #1) > Audacious upstream announced they're going to remove the GTK+2 code this > release [1], so that explains the ebuild. > > Nobody @gentoo has really paid any attention to audacious for the last few > years so I'll elaborate: GTK+ is already lagging behind the Qt5 GUI in > feature support (none of the new plugins work on it and the last few > GTK-only ones are in the process of being ported) and - more importantly - > nobody's stepped up to add it to the new build system that's replaced the > old Autocruft code. That's being kept on life support so they can do a win32 > binary release of 4.0 without holding everything else up, but after that > it's all gone for good. > > While I can empathise with the desire to keep using GTK+2, it's better to > get it over with and rip off the bandage now. It's not like it's downgrading > you to Gtk3. > > > [1]: https://redmine.audacious-media-player.org/boards/1/topics/2436 Well I hope the global hotkeys plugin will be readded before 4.x goes stable. I did not see it in the beta1 release.
(In reply to Andreas Sturmlechner from comment #2) > Upstream has switched to qt5 by default and beta testing is targeting the > default only. Re-adding the substantial ebuild complexity for gtk2 may be > only worthwhile in case defects are uncovered in the qt5 implementation that > for some reason are substantial enough that upstream can not fix your bugs > in time for the final release. I wasn't aware that it was going away. I just noticed that global hotkeys disappeared when upgrading and I'm not sure if that was ever available for the qt side since I always compiled with gtk support.
(In reply to Matthew Schultz from comment #3) > Well I hope the global hotkeys plugin will be readded before 4.x goes > stable. I did not see it in the beta1 release. Don't worry, they're aware of it.
Created attachment 612058 [details] 4.10-beta1 ebuild add support for gtk2
Created attachment 612060 [details] metadata add 'gtk2' useflag to remove ambiguity. leave old 'gtk' flag in there for the old packages to still work until someone bothered to adjust them if needed.
Created attachment 612062 [details] add gtk2ui support for audacious's plugins
Created attachment 612064 [details] audacious-plugins's metadata add 'gtk2' useflag to resolve ambiguity. keep old 'gtk' flag in there for compatibility with older ebuilds
Comment on attachment 612060 [details] metadata This is audacious's metadata
Use of gtk2 flag is against gnome proj policy. Users you wish to stay with GTK2 version for now can keep using 3.10.1.
(In reply to Andreas Sturmlechner from comment #11) > Use of gtk2 flag is against gnome proj policy. > Users you wish to stay with GTK2 version for now can keep using 3.10.1. First, Audacious is not a GNOME project. Second, gtk2 is the Gimp toolkit not the GNOME toolkit. Third, There are more desktop environments and window managers then GNOME3, and lastly my linux desktop experience should not have to suffer every time a large corporation like RedHat wants to throw their weight around. These ebuilds I supplied work, and the reasoning laid out before for not doing it "it's too difficult" or "adds too much complexity to the ebuild" were not true as you can see by diffing my ebuilds with the current 4.10 beta1
I'm not sure why you go on about gnome3 and what GTK is or not. RedHat certainly did not port audacious to Qt5, which we are using here.
Can you please point to me where the GNOME project has such a policy and why it matters for audacious?
(In reply to Thomas Groman from comment #12) > (In reply to Andreas Sturmlechner from comment #11) > > Use of gtk2 flag is against gnome proj policy. > > Users you wish to stay with GTK2 version for now can keep using 3.10.1. > > First, Audacious is not a GNOME project. Second, gtk2 is the Gimp toolkit > not the GNOME toolkit. Third, There are more desktop environments and window > managers then GNOME3, and lastly my linux desktop experience should not have > to suffer every time a large corporation like RedHat wants to throw their > weight around. > > These ebuilds I supplied work, and the reasoning laid out before for not > doing it "it's too difficult" or "adds too much complexity to the ebuild" > were not true as you can see by diffing my ebuilds with the current 4.10 > beta1 Sorry, but your hostile and abrasive style coupled with the leading diatribe will most definitely not lead us to include your ebuild. Gtk2 is dead, and Qt5 in Audacious is here to stay as mentioned earlier.
> Gtk2 is dead, and > Qt5 in Audacious is here to stay as mentioned earlier. What do you mean by 'Gtk2 is dead' and you mentioned qt5 staying. My goal is not to remove qt5, simply to add gtk2 as an option. Are you having trouble building with the qt5 use flag turned on?
> Sorry, but your hostile and abrasive style coupled with the leading diatribe > will most definitely not lead us to include your ebuild. My response was more than reasonable. If your feel the tone used was "hostile and abrasive" it was not intended that way.
(In reply to Thomas Groman from comment #16) > > Gtk2 is dead, and > > Qt5 in Audacious is here to stay as mentioned earlier. > > What do you mean by 'Gtk2 is dead' and you mentioned qt5 staying. My goal is > not to remove qt5, simply to add gtk2 as an option. Are you having trouble > building with the qt5 use flag turned on? https://redmine.audacious-media-player.org/boards/1/topics/1269 "The long-term goal is still to switch to Qt."
(In reply to Thomas Groman from comment #17) > My response was more than reasonable. If your feel the tone used was > "hostile and abrasive" it was not intended that way. In your response you didn't give us a single reason to add a GTK option. Instead you made a RedHat detour, and what is tolerated in the forums we do not appreciate in a bug tracker. It is, quite simply, offtopic. https://wiki.gentoo.org/wiki/Project:GNOME/Gnome_Team_Ebuild_Policies#GTK.2B_USE-flag_and_slots_usage "gtk USE flag means gtk+ support, whatever slot is needed by the package using it" But that is really irrelevant, as you didn't get the most basic thing right, that is, enforcing either one or the other toolkit, making the plugins depend on the same toolkit version of the application, and restricting several USE flags based on toolkit choice where needed. Such an ebuild may work for you privately, but is not fit for the tree.
> https://wiki.gentoo.org/wiki/Project:GNOME/Gnome_Team_Ebuild_Policies#GTK. > 2B_USE-flag_and_slots_usage > > "gtk USE flag means gtk+ support, whatever slot is needed by the package > using it" That's not a very well thought out policy. What happens when a ebuild can be built with BOTH slots and you want to pick :2 not :3 ? Are there any accommodations for this? > But that is really irrelevant, as you didn't get the most basic thing right, > that is, enforcing either one or the other toolkit, making the plugins > depend on the same toolkit version of the application, and restricting > several USE flags based on toolkit choice where needed. Then lets work on fixing that.
Let me refer you back to comment #2 instead. Use the package with Qt5, help upstream by reporting any bugs, make it a great 4.0 release. Barring a really good reason GTK2 will not come back in this package.
(In reply to Andreas Sturmlechner from comment #21) > Let me refer you back to comment #2 instead. > > Use the package with Qt5, help upstream by reporting any bugs, make it a > great 4.0 release. > > Barring a really good reason GTK2 will not come back in this package. Are you saying users wanting it is not a good reason? So what do I need to do, sumbit a completely new ebuild as it's own package, maybe audacious-gtk2?
A new package to bring back a deprecated codepath for a deprecated toolkit that you might as well just get by emerging audacious-3.10.1?
(In reply to Thomas Groman from comment #22) > (In reply to Andreas Sturmlechner from comment #21) > > Let me refer you back to comment #2 instead. > > > > Use the package with Qt5, help upstream by reporting any bugs, make it a > > great 4.0 release. > > > > Barring a really good reason GTK2 will not come back in this package. > > Are you saying users wanting it is not a good reason? So what do I need to > do, sumbit a completely new ebuild as it's own package, maybe audacious-gtk2? Users wanting something is not an absolute reason for adding something. Maintainer and upstream preferences also need to be taken into account.
