Bug 43943 - Freedesktop needs to define a way to get/set the default icon theme
Summary: Freedesktop needs to define a way to get/set the default icon theme
Alias: None
Product: Portland
Classification: Unclassified
Component: Portland (show other bugs)
Version: unspecified
Hardware: Other All
: medium major
Assignee: Jerome Leclanche
QA Contact:
Depends on:
Reported: 2011-12-18 19:01 UTC by Jerome Leclanche
Modified: 2019-02-16 13:34 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

theme-config-spec 0.1 (13.21 KB, text/html)
2012-03-26 12:52 UTC, Jerome Leclanche

Description Jerome Leclanche 2011-12-18 19:01:20 UTC
Currently there is no way to get the default icon theme from system files. This is an issue when using a DE that is not based on gnome or kde.

This leads to the following code in Qt, which breaks outside of gnome/kde and results in an unmodifiable icon theme:

/* the default icon theme name for QIcon::fromTheme. */
QString QGuiPlatformPlugin::systemIconThemeName()
    QString result;
#ifdef Q_WS_X11
    if (X11->desktopEnvironment == DE_GNOME) {
        result = QString::fromLatin1("gnome");
        result = QGtkStylePrivate::getGConfString(QLatin1String("/desktop/gnome/interface/icon_theme"), result);
    } else if (X11->desktopEnvironment == DE_KDE) {
        result =  X11->desktopVersion >= 4 ? QString::fromLatin1("oxygen") : QString::fromLatin1("crystalsvg");
        QSettings settings(QKde::kdeHome() + QLatin1String("/share/config/kdeglobals"), QSettings::IniFormat);
        result = settings.value(QLatin1String("Theme"), result).toString();
    return result;

An implementation (don't remember which one) creates a theme called "default" and an index.theme symlinked to the chosen default theme.
Issue with adopting that is the lack of control over multiple defaults.

What I propose:
A defaults.list file which specifies the preferred themes. Example file:






Keys are listed in order of priority. If a theme cannot be found or does not match the current configuration, the next one is chosen, until a theme is found to exist. hicolor is always the last fallback.

The described file specifies that the default global theme is oxygen.
If oxygen cannot be found, in gnome only, we check if the "gnome" icon theme exists and use it if it does.
If we still don't have a theme, if we are not in KDE we try the tango theme.
If we still don't have a theme, we try "mygenerictheme".
If we still don't have a theme, we try "myfallbacktheme".

Finally, if none of those themes work, we default to hicolor.

unrelated: in the "Directory layout" section, there should be a mention of whether svgz files are allowed or not.
Comment 1 Jerome Leclanche 2012-03-19 11:51:09 UTC
From razor mailing list:

Yes, you're correct, the order of keys should not matter. That was a bad idea.

It's kind of tricky though, because DontShowIn/OnlyShowIn are kind of essential, imho.

How about this. It simplifies the format a little, too:


[Theme gnome]

[Theme tango]


Note that if the theme does not have to be present in the list in order to be specified in the Ordering key, as we just want the names. It should only be specified if there is extra metadata to attach to the name. (If "theme <name>" is a problem, we can just do like the old format, [Theme]  Name=<name>)
Preferences might need a better name, but it leaves the door open for further customization.

We might even want something like:

etc. Just a thought.
Comment 2 Jerome Leclanche 2012-03-26 12:52:29 UTC
Created attachment 59086 [details]
theme-config-spec 0.1

Attached is the spec I worked on for this, along with fixes from comments on Razor / xdg / gnome / qt lists and irc channels.

The gnome guys seem to disagree with the spec and insist that the settings should be for the DE to worry about, and that getting the current icon/sound/cursor theme should be done through xsettings. I see their point, so I'm putting a hold on this spec.

I'm leaving it attached here so that if it's ever decided to store theme settings globally, work can be picked up from here.
Comment 3 GitLab Migration User 2019-02-16 13:34:40 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xdg/xdg-utils/issues/54.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.