There's no proper replacement for KIcon
Albert Astals Cid
aacid at kde.org
Thu Sep 11 07:33:23 UTC 2014
El Dijous, 11 de setembre de 2014, a les 08:46:11, Kevin Krammer va escriure:
> 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.
Correct.
> Assuming that is the case it would have implied for me that an icon of this
> name is always present.
Should be always present in valid themes, yes.
> 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?
There's no hicolor "theme" per se. Only a bunch of empty folders
http://www.freedesktop.org/software/icon-theme/releases/hicolor-icon-theme-0.5.tar.gz
Cheers,
Albert
>
> Cheers,
> Kevin
More information about the Kde-frameworks-devel
mailing list