Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 701450 - media-sound/audacious-4.0_beta1 should support GTK+
Summary: media-sound/audacious-4.0_beta1 should support GTK+
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Jason A. Donenfeld
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-11-29 07:05 UTC by Matthew Schultz
Modified: 2020-06-02 09:33 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
4.10-beta1 ebuild (audacious-4.0_beta1.ebuild,1.86 KB, text/plain)
2020-02-06 04:41 UTC, Thomas Groman
Details
metadata (metadata.xml,546 bytes, text/xml)
2020-02-06 04:42 UTC, Thomas Groman
Details
add gtk2ui support for audacious's plugins (audacious-plugins-4.0_beta1-r2.ebuild,4.19 KB, text/plain)
2020-02-06 04:43 UTC, Thomas Groman
Details
audacious-plugins's metadata (metadata.xml,1.40 KB, text/xml)
2020-02-06 04:45 UTC, Thomas Groman
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Schultz 2019-11-29 07:05:50 UTC
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
Comment 1 Anthony Parsons 2019-11-29 09:45:30 UTC
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
Comment 2 Andreas Sturmlechner gentoo-dev 2019-11-29 18:41:58 UTC
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.
Comment 3 Matthew Schultz 2019-11-29 20:51:27 UTC
(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.
Comment 4 Matthew Schultz 2019-11-29 20:52:43 UTC
(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.
Comment 5 Anthony Parsons 2019-11-30 01:23:22 UTC
(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.
Comment 6 Thomas Groman 2020-02-06 04:41:08 UTC
Created attachment 612058 [details]
4.10-beta1 ebuild

add support for gtk2
Comment 7 Thomas Groman 2020-02-06 04:42:30 UTC
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.
Comment 8 Thomas Groman 2020-02-06 04:43:50 UTC
Created attachment 612062 [details]
add gtk2ui support for audacious's plugins
Comment 9 Thomas Groman 2020-02-06 04:45:14 UTC
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 10 Thomas Groman 2020-02-06 04:45:48 UTC
Comment on attachment 612060 [details]
metadata

This is audacious's metadata
Comment 11 Andreas Sturmlechner gentoo-dev 2020-02-06 10:17:46 UTC
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.
Comment 12 Thomas Groman 2020-02-06 22:30:41 UTC
(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
Comment 13 Andreas Sturmlechner gentoo-dev 2020-02-06 22:35:10 UTC
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.
Comment 14 Thomas Groman 2020-02-06 23:12:33 UTC
Can you please point to me where the GNOME project has such a policy and why it matters for audacious?
Comment 15 David Seifert gentoo-dev 2020-02-06 23:13:25 UTC
(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.
Comment 16 Thomas Groman 2020-02-06 23:19:36 UTC
> 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?
Comment 17 Thomas Groman 2020-02-06 23:22:16 UTC
> 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.
Comment 18 David Seifert gentoo-dev 2020-02-06 23:24:52 UTC
(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."
Comment 19 Andreas Sturmlechner gentoo-dev 2020-02-06 23:27:28 UTC
(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.
Comment 20 Thomas Groman 2020-02-06 23:40:44 UTC
> 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.
Comment 21 Andreas Sturmlechner gentoo-dev 2020-02-06 23:47:17 UTC
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.
Comment 22 Thomas Groman 2020-02-06 23:54:11 UTC
(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?
Comment 23 Andreas Sturmlechner gentoo-dev 2020-02-07 00:00:49 UTC
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?
Comment 24 David Seifert gentoo-dev 2020-02-07 09:20:27 UTC
(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.