Discussion:
Definition of the current icon theme
Роман Чистоходов
2017-01-28 21:57:54 UTC
Permalink
Icon Theme Specification mentions "current theme", but does not elaborate
on what it is and how it can be detected, making it very hard for authors
of third-party applications or GUI toolkits to detect this "current theme"
for correct icon resolving (it becomes much like guessing game)

It seems like detection of the current icon theme is DE-dependent right
now. Would be useful to have specification that defines how desktop
environments should store the name of current icon theme, how applications
can find it and how applications can receive icon theme updates (e.g. user
changes icon theme and applications want to reload icons to reflect this
change).

Super simple solution is to write the name of icon theme (and nothing else)
to $XDG_CONFIG_HOME/icon-theme-name.txt file whenever DE is starting or
setting different icon theme. Applications may read file and watch it for
changes (using platform-dependent API).

Until this is not implemented by desktop environments, sensible fallback
may be specified for each popular DE.
Markus Raab
2017-01-29 21:22:59 UTC
Permalink
Hi,
Post by Роман Чистоходов
Icon Theme Specification mentions "current theme", but does not elaborate
on what it is and how it can be detected, [...]
It seems like detection of the current icon theme is DE-dependent right
now. [...] Applications may read file and watch it for
changes (using platform-dependent API).
Until this is not implemented by desktop environments, sensible fallback
may be specified for each popular DE.
Elektra implements DE detection in https://www.libelektra.org/plugins/desktop
and we gladly accept desktop icons detection. It would give the desired
features (e.g. notification via https://www.libelektra.org/plugins/dbus) and
the plugin could implement fallbacks in the case nobody writes into the KDB.

Btw. why didn't you suggest dbus?

best regards,
--
Markus Raab https://www.libelektra.org
Technische UniversitÀt Wien ***@markus-raab.org
Institut fÃŒr Computersprachen Phone: (+431) 58801/185185
Argentinierstr. 8, 1040 Wien, Austria FAX: (+431) 58801/18598

DVR 0005886
Роман Чистоходов
2017-01-30 10:51:10 UTC
Permalink
Sorry, I forgot to include ***@lists.freedesktop.org in recipients.
Duplicate my own message:

dbus is just another dependency, it's not always desirable in application
and it's not even used in every DE. E.g. Lumina desktop works without it.
Actually it was pointed out in irc chat that freedesktop has xsettings
specification https://www.freedesktop.org/wiki/
Specifications/xsettings-spec/ and Net/IconThemeName in XSettingsRegistry
https://www.freedesktop.org/wiki/Specifications/XSettingsRegistry/
I don't know how widely this spec is accepted in desktop environments, it's
only a draft. Also it's designed for X, so not display server independent.
Remember we also have Wayland and Mir and actually nothing can stop us from
following the most of freedesktop specs on completely other platforms (e.g.
there's KDE for Windows and OSX).

There also was a message by Alexander Sokolov, which he sends only to me,
and not xdg. He probably would want to resend it himself.
Post by Markus Raab
Hi,
Post by Роман Чистоходов
Icon Theme Specification mentions "current theme", but does not elaborate
on what it is and how it can be detected, [...]
It seems like detection of the current icon theme is DE-dependent right
now. [...] Applications may read file and watch it for
changes (using platform-dependent API).
Until this is not implemented by desktop environments, sensible fallback
may be specified for each popular DE.
Elektra implements DE detection in https://www.libelektra.org/
plugins/desktop
and we gladly accept desktop icons detection. It would give the desired
features (e.g. notification via https://www.libelektra.org/plugins/dbus) and
the plugin could implement fallbacks in the case nobody writes into the KDB.
Btw. why didn't you suggest dbus?
best regards,
--
Markus Raab https://www.libelektra.org
Institut fÃŒr Computersprachen Phone: (+431) 58801/185185
Argentinierstr. 8, 1040 Wien, Austria FAX: (+431) 58801/18598
DVR 0005886
_______________________________________________
xdg mailing list
https://lists.freedesktop.org/mailman/listinfo/xdg
Александр Соколов
2017-01-30 11:27:11 UTC
Permalink
Absolutely agree, we don't have easy way to know the icon theme name, and
this makes the Icon Theme Specification
<https://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html>
is
almost meaningless. We need a simple way to get the current icon theme name.

There are 2 proposals, XSETTINGS
<https://specifications.freedesktop.org/xsettings-spec/xsettings-spec-0.5.html>
and XSettingsRegistry
<https://www.freedesktop.org/wiki/Specifications/XSettingsRegistry/>. But
XSETTINGS does not work:
1. It is difficult to implement in the low-level languages like C or C++.
2. It is impossible to implement it in a scripting language such as bash.
3. It cannot be used in Wayland.

But using a single file has a problem. One DE will overwrite the settings
of another. My suggestion is.

DE defines a XDG_CONFIG_PREFIX variable, and settings are read from the
file ${$XDG_CONFIG_DIRS}/{XDG_CONFIG_PREFIX}xdg-settings.ini
It's similar to the approach of the menu-spec
<https://specifications.freedesktop.org/menu-spec/menu-spec-1.0.html>
specifications.

This will allow different DE have different settings in the different
configuration files.

Additionally I propose to use a INI-like config file format. This has the
following advantages:
1. The format is familiar to programmers.
2. It allows you to have some grouping of values.
3. Because desktop-files are INI, the code implementing your
specifications already have a parser for that format.
Post by Markus Raab
Btw. why didn't you suggest dbus?
IMHO the specification should be as simple as possible. In any case, we can
write dbus service for reading and changing the values. But the approach
should be maximized simple. Otherwise programmers will not use it.
Post by Markus Raab
Icon Theme Specification mentions "current theme", but does not elaborate
on what it is and how it can be detected, making it very hard for authors
of third-party applications or GUI toolkits to detect this "current theme"
for correct icon resolving (it becomes much like guessing game)
It seems like detection of the current icon theme is DE-dependent right
now. Would be useful to have specification that defines how desktop
environments should store the name of current icon theme, how applications
can find it and how applications can receive icon theme updates (e.g. user
changes icon theme and applications want to reload icons to reflect this
change).
Super simple solution is to write the name of icon theme (and nothing
else) to $XDG_CONFIG_HOME/icon-theme-name.txt file whenever DE is
starting or setting different icon theme. Applications may read file and
watch it for changes (using platform-dependent API).
Until this is not implemented by desktop environments, sensible fallback
may be specified for each popular DE.
_______________________________________________
xdg mailing list
https://lists.freedesktop.org/mailman/listinfo/xdg
--
Best regards,
Alexander.
Simon McVittie
2017-01-30 12:23:28 UTC
Permalink
Super simple solution is to write the name of icon theme (and nothing else) to
 $XDG_CONFIG_HOME/icon-theme-name.txt file whenever DE is starting or setting
different icon theme
I can't help thinking that a desktop environment should really be able to
start up without writing to disk, and that writes to $XDG_CONFIG_HOME should
only happen when some interesting event occurs (like a user changing
configuration).

$XDG_RUNTIME_DIR?

S
Александр Соколов
2017-01-30 15:58:40 UTC
Permalink
Post by Simon McVittie
I can't help thinking that a desktop environment should really be able to
start up without writing to disk, and that writes to $XDG_CONFIG_HOME should
only happen when some interesting event occurs (like a user changing
configuration).
If we will use XDG_CONFIG_DIRS and XDG_CONFIG_DIR, then no problem.
At the start desktop environment will look for files in the following order:
1. ~/.config/${XDG_CONFIG_PREFIX}xdg-settings.ini
2. ~/.config/xdg-settings.ini
3. /etc/xdg/${XDG_CONFIG_PREFIX}xdg-settings.ini
4. /etc/xdg/xdg-settings.ini

So, if user config not exists then global settings will be used from
/etc/xdg.
Post by Simon McVittie
--
Best regards,
Alexander.
Thiago Macieira
2017-01-30 21:17:28 UTC
Permalink
Post by Simon McVittie
Post by Роман Чистоходов
Super simple solution is to write the name of icon theme (and nothing
else) to $XDG_CONFIG_HOME/icon-theme-name.txt file whenever DE is
starting or setting different icon theme
I can't help thinking that a desktop environment should really be able to
start up without writing to disk, and that writes to $XDG_CONFIG_HOME should
only happen when some interesting event occurs (like a user changing
configuration).
Not to mention that the different DEs might be started on multiple seats
sharing a $HOME mount (if not the same machine), so writing to a file is not a
good idea.
Post by Simon McVittie
$XDG_RUNTIME_DIR?
Better.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
Loading...