On Wednesday, 2014-09-10, 23:43:15, Albert Astals Cid wrote: > El Dimarts, 9 de setembre de 2014, a les 16:25:26, Kevin Krammer va escriure: > > On Sunday, 2014-09-07, 10:27:06, Albert Astals Cid wrote: > > > So as I see it, there's three options: > > > * Do nothing, and expect that people have to set one of > > > > > > XDG_CURRENT_DESKTOP, KDE_FULL_SESSION, GNOME_DESKTOP_SESSION_ID or > > > DESKTOP_SESSION environment variables to get icons > > > > > > * Do the change/hack to QGenericUnixTheme::themeHint return any of the > > > > > > themes in xdgIconThemePaths that is not hicolor > > > > > > * Talk to the xdg-people to include a way to get the current icon theme > > > and > > > > > > use that in QGenericUnixTheme::themeHint > > > > Wouldn't a fourth option be to make sure that hicolor is actually a proper > > fallback as specified? > > > > Applications already are more or less required to install their fallbacks > > in hicolor, so the shared icons should be there as well, no? > > I don't think it makes sense, i mean who would install stuff to > hicolor/actions/document-open.png ? oxygen? breeze? tango? someothericonset? > > For applications it makes sense tha application to install to hicolor since > the application "owns" the name for that icon, but noone actually owns the > document-open.png action so that's why i think it makes no sense for it to > be there.
The rule to always also install an application icon into Hicolor was meant as an example of a general intent that Hicolor be fully usable. I don't know the details of the icon spec but my understanding was that "document-open" was a specified standard name. Assuming that is the case it would have implied for me that an icon of this name is always present. If not in the current theme then at least in the fallback Hicolor theme. Again based on these prior assumptions on the spec, not having that icon in Hicolor would constitute a bug in the Hicolor theme and should be fixed by adding the icon there,no? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
