Since version 0.8.2, SMPlayer provides a new, skin-based interface. I submitted bug 469628 that adds an ebuild for the skins package. On the smplayer ebuild side, a new "skins" USE flag would control this. I am attaching a patch here, that adds that USE flag to all the smplayer ebuilds currently in portage (0.8.3, 0.8.4 and 0.8.4-r1). The USE flag is not enabled by default. However, since version 0.8.5 of SMPlayer (bug 469368), the skinable GUI is made the default by upstream, so the ebuild for that version should most probably use "+skins" to reflect that default. Since adding this USE flag depends on the existence of the smplayer-skins package, a blocker is needed in bug 469628. Reproducible: Always
Created attachment 348118 [details] Adds "skin" USE flag to all current smplayer ebuilds.
There's no need for two bugs for such requests, imo.
We don't normally add useflags for such optional add-ons.
(In reply to comment #3) > We don't normally add useflags for such optional add-ons. It's not optional. It's the new upstream default. The "Skinable GUI" option in the SMPlayer preferences dialog will be grayed out otherwise, even though it should be the default. You can read about it here: http://smplayer.sourceforge.net/forum/viewtopic.php?f=3&t=6203 If the USE flag isn't to be added, then x11-themes/smplayer-skins should be put in RDEPEND unconditionally. I suggested the USE flag for users who don't want the new upstream default. I thought that Gentoo policy was that ebuild defaults should reflect upstream defaults.