In Road To Qt, Audacious Switches From GTK3 Back To GTK2

[Luke]

Deletig "symbolic" icons can force fallback to theme icons

The device icons changed for the Hicolor and Oxygen themes, the folder icons stayed the same. When the filechooser is not the active window, all if it is made grayer, including the icons.

I found the icons you describe-all of them in light gray. I'll see what happens if I add icons under those filenames in my own theme.

Deleting all scaleable icons in GNOME prevents the filechooser from using them, though I would perfer to be able to override that fallback within my own theme so I would not have to modify the GNOME theme every time it updates. Still chasing down a few isolated monochrome icons, but this got most of them out of my theme in whch they don;t fit.

[psychoticmeow]

Deleting all scaleable icons in GNOME prevents the filechooser from using them, though I would perfer to be able to override that fallback within my own theme so I would not have to modify the GNOME theme every time it updates. Still chasing down a few isolated monochrome icons, but this got most of them out of my theme in whch they don;t fit.

Not an ideal outcome I know, but it's something. I've had a quick search for bugs to see if this has been reported, I only found: Support non-svg symbolic icons.

Perhaps put in a feature request, so at least the problem is known.

[FLHerne]

The C++ preprozessor might be a weird thing, i.e. newer languages like Java, Python, Go, etc. don't need one. It is a legacy from C.

He's not referring to the standard C++ preprocessor - which, while rather clunky, is at least familiar to all C or C++ devs - but to the moc. Which is rather weird and difficult to understand the effect of, and specific to Qt.

OTOH, moc isn't a hard requirement and Qt is awesome regardless.

[Luke]

How do I do a feature request?

Not an ideal outcome I know, but it's something. I've had a quick search for bugs to see if this has been reported, I only found: Support non-svg symbolic icons.

Perhaps put in a feature request, so at least the problem is known.

How would I go about a feature request, one to support enabling or disabling "shading" icons labelled "symbolic." That feature would mandate use of icons not done in the greyscale normally used for these icons, so they would have reasonable contrast. Purpose would be to support use of colored icons matching comparable icons elsewhere in an icon theme. Some packages like Cinnamon, gnome-shell, and various applets for both won't load anything but "symbolic" icons, they could still be permitted to shade them so long as this can be turned off in things like sidebars and menus.

I finally managed to get rid of all the black icons in the filechooser except the trash can, for which no substitute worked, so I added that one back. Had to remove ALL of the "scaleable" icons in the gnome folder in /usr/share/icons, essentially turning gnome-icon-theme-symbolic into an empty package. I will .deb that empty package up for now. Had to add some back in "symbolic" folders in /usr/share/icons/UbuntuStudio-Legacy(my theme) to get Cinnamon to show icons for some applets. Unfortunately, one of those was in "devices" so the removable device applet had to go. If the folder exists but not the icon, the filechooser will show missing icons rather than fall back to the theme icons.

A post on an Ubuntu forum finally explained how these icons work: they are greyscale, designed to be displayed lighter or darker depending on the background, using theme foreground color as the basic guide. Thus, a removable device icon would show white on a black background in a Cinnamon or Gnome-shell applet with the black "GNOME" theme on the panel, yet show black on the white background in the filechooser. The post said remaking the icons in Inkscape to not support a property called "stroke" would force them to render in original colors regardless of background. Right now I don't want to download a 60MB package on a non-landline connection to test that but will play with it sometime. If I can get it to work, the 0.5 version of my icon theme won't need to replace gnome-icon-theme-symbolic with an empty package anymore.

[0xBADCODE]

FAIL!

That's FAIL. Those who wants something similar but Qt-based can use qmmp for *ages* already. I fail to see why Audacious should turn into some ripoff of qmmp. Should it go Qt, I fail to see any reasons to use Audacious (I use it in XFCE based system and not really warmly welcome Qt programs here). But ok, thanks for forewarning, dear devs. I would plan my move to some other player, e.g. deadbeef.

[johnc]

That's FAIL. Those who wants something similar but Qt-based can use qmmp for *ages* already. I fail to see why Audacious should turn into some ripoff of qmmp. Should it go Qt, I fail to see any reasons to use Audacious (I use it in XFCE based system and not really warmly welcome Qt programs here). But ok, thanks for forewarning, dear devs. I would plan my move to some other player, e.g. deadbeef.

Why would the toolkit matter for the user other than the fact that GTK3 is an extraordinarily slow and bloated pile of crap? The toolkit is more about the developers' needs. In theory it should be completely transparent to the user (again, except for the fact that GTK3 is absolutely awful in every conceivable way.)

[anda_skoa]

OTOH, moc isn't a hard requirement and Qt is awesome regardless.

And it is not a preprocessor, hence my misunderstanding.

Anyway, thanks for clarifying

Cheers,
_

[ssokolow]

That's FAIL. Those who wants something similar but Qt-based can use qmmp for *ages* already. I fail to see why Audacious should turn into some ripoff of qmmp. Should it go Qt, I fail to see any reasons to use Audacious (I use it in XFCE based system and not really warmly welcome Qt programs here). But ok, thanks for forewarning, dear devs. I would plan my move to some other player, e.g. deadbeef.

I'm sure they'll be so heartbroken. I look forward to seeing your fork of the Audacious codebase show up on GitHub.

[FLHerne]

And it is not a preprocessor, hence my misunderstanding.

Well, in the literal sense of processing code before the compiler sees it, I don't think the OP calling it a 'preprocessor' was that wide of the mark.
Anyway, it's nice to have a short dicussion on Phoronix that doesn't instantly become a flamewar.
Thanks.

[erendorn]

And it is not a preprocessor, hence my misunderstanding.

Anyway, thanks for clarifying

Cheers,
_

How is it not a preprocessor? What definition of preprocessor do you use to reach that conclusion?