Expand os-release spec with LOGO

[h***@opensuse.org]

Hi,

A few months ago a discussion happened about changing display logo for
Gnome
depending on os-release file [1].

However spec [2] doesn't cover DEs wanting to add items to it, just
OSes, which
will still not be great, if support would have to be extended to
SUSE_LOGO,
DEBIAN_LOGO, UBUNTU_LOGO etc.

KDE does this by having that stuff specified in
/etc/xdg/kcm-about-distrorc [3],
which is not great, because again, it's kind of info that easily could
be in
os-release for every DE and app that might need it. Both DEs require
information
about logo location, would be nice to provide it once, for all that
might require
it in the future.

Suggestion I would give about it would be to allow for either full path
or a
name to be used with xdg-icon standard.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=695691
[2] https://www.freedesktop.org/software/systemd/man/os-release.html
[3]
https://github.com/openSUSE/plasma-opensuse/blob/leap-15.x/config-files/etc/xdg/kcm-about-distrorc
LCP [Stasiek]
https://lcp.world

[Jeremy Bicha]

Post by h***@opensuse.org
However spec [2] doesn't cover DEs wanting to add items to it, just
OSes, which
will still not be great, if support would have to be extended to
SUSE_LOGO,
DEBIAN_LOGO, UBUNTU_LOGO etc.

I think the GNOME proposal does do what you are requesting.

I don't understand your comment about desktop environments needing
special icons. For most distros, there is only one icon: Fedora is
Fedora no matter what desktop environment you use.

I would expect a desktop environment about system dialog to show this
new os-release distro icon and fall back to a generic icon (like the
GNOME foot) if there is no os-release icon.

/etc/os-release is about system-level stuff. For instance, Ubuntu and
Kubuntu have the same /etc/os-release file. If Kubuntu wants to show a
different system logo, it can just ship its version in its default
icon theme. Or Debian-based distros can use the update-alternatives
system.

Despite the discussion on the GNOME bug, I don't think anyone has
proposed the addition to either this list or systemd yet.

Thanks,
Jeremy Bicha

[h***@opensuse.org]

Post by Jeremy Bicha

Post by h***@opensuse.org
However spec [2] doesn't cover DEs wanting to add items to it, just
OSes, which
will still not be great, if support would have to be extended to
SUSE_LOGO,
DEBIAN_LOGO, UBUNTU_LOGO etc.

I think the GNOME proposal does do what you are requesting.
I don't understand your comment about desktop environments needing
special icons. For most distros, there is only one icon: Fedora is
Fedora no matter what desktop environment you use.

From my understanding OS is the end product of vendor putting out
distro
under certain name. In that case GNOME_LOGO is not a viable entry under
this spec, because Gnome is just a component of a functioning operating
system under other name (except for distros that call themselves Gnome
Next and stuff to that effect). GNOME_LOGO is something that was
proposed
earlier in bgo thread to acommodate for that spec's suggestion.

Post by Jeremy Bicha
I would expect a desktop environment about system dialog to show this
new os-release distro icon and fall back to a generic icon (like the
GNOME foot) if there is no os-release icon.
/etc/os-release is about system-level stuff. For instance, Ubuntu and
Kubuntu have the same /etc/os-release file. If Kubuntu wants to show a
different system logo, it can just ship its version in its default
icon theme. Or Debian-based distros can use the update-alternatives
system.

I forgot that Ubuntu spins don't have their own repos, you are
absolutely
right!

Post by Jeremy Bicha
Despite the discussion on the GNOME bug, I don't think anyone has
proposed the addition to either this list or systemd yet.
Thanks,
Jeremy Bicha

That's why I thought to bring it up. It would be great to start with
adding LOGO to the spec, before starting any work that would fall
outside
of spec and make the LOGO entry in spec an afterthought.

LCP [Stasiek]
https://lcp.world

[Lennart Poettering]

Hi,
A few months ago a discussion happened about changing display logo for Gnome
depending on os-release file [1].
However spec [2] doesn't cover DEs wanting to add items to it, just OSes,
which
will still not be great, if support would have to be extended to SUSE_LOGO,
DEBIAN_LOGO, UBUNTU_LOGO etc.
KDE does this by having that stuff specified in /etc/xdg/kcm-about-distrorc
[3],
which is not great, because again, it's kind of info that easily could be in
os-release for every DE and app that might need it. Both DEs require
information
about logo location, would be nice to provide it once, for all that might
require
it in the future.
Suggestion I would give about it would be to allow for either full path or a
name to be used with xdg-icon standard.

The man page (which is also the spec) os-release(5) is maintained as
part of systemd btw, it's probably better to discuss this request in a
github issue.

The request generally makes sense to me, but I am a bit unsure about
how this should actually look like.

What value should the field take? Some options:

1. An embedded base64 blob? (probably not, might grow too large; also
doesn't support multiple resolutions)

2. A path to some SVG or PNG file? (Not sure, might not be a good fit,
as the path to a single bitmap probably wouldn't cover the
necessities for multiple resolutions that well. Also, instead of
embedded a file path in the os-release file, I think it would be
more natural to simply define /{usr/lib|etc}/os-logo.{png|svg} or so
instead, i.e. standardize the name and expect the same search path
logic as for /{usr/lib|etc}/os-release itself.

3. A "named icon" according to the icon naming/theming specs?
[https://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html
and
https://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html]
(this would solve the resolution problem, but maybe might be a bit
overkill, a logo is not an icon after all, and "themed logos" are a
weird concept...)

Maybe a combination of option 3 and the os-logo.{png|svg} idea could
work, so that downstreams can choose whether they want the
comprehensive solution or the easy and slightly sloppy one.

This also reminds me of this:

https://blog.verbum.org/2008/07/28/etcfavicon-png/

Which to my knowledge never got much traction but still makes me
wonder whether any new spec should cover that use case too, since it's
so very similar.

I'd be willing to merge something like this for os-release(5) if this
makes sense to everyone. Please prep a PR adding this to the xml
docbook of systemd:

https://github.com/systemd/systemd/blob/master/man/os-release.xml

(if we go the os-logo.{png|svg} route then I figure this should have a
new man page of its own)

Lennart

[Simon Lees]

Post by Lennart Poettering

Hi,
A few months ago a discussion happened about changing display logo for Gnome
depending on os-release file [1].
However spec [2] doesn't cover DEs wanting to add items to it, just OSes,
which
will still not be great, if support would have to be extended to SUSE_LOGO,
DEBIAN_LOGO, UBUNTU_LOGO etc.
KDE does this by having that stuff specified in /etc/xdg/kcm-about-distrorc
[3],
which is not great, because again, it's kind of info that easily could be in
os-release for every DE and app that might need it. Both DEs require
information
about logo location, would be nice to provide it once, for all that might
require
it in the future.
Suggestion I would give about it would be to allow for either full path or a
name to be used with xdg-icon standard.

The man page (which is also the spec) os-release(5) is maintained as
part of systemd btw, it's probably better to discuss this request in a
github issue.
The request generally makes sense to me, but I am a bit unsure about
how this should actually look like.
1. An embedded base64 blob? (probably not, might grow too large; also
doesn't support multiple resolutions)
2. A path to some SVG or PNG file? (Not sure, might not be a good fit,
as the path to a single bitmap probably wouldn't cover the
necessities for multiple resolutions that well. Also, instead of
embedded a file path in the os-release file, I think it would be
more natural to simply define /{usr/lib|etc}/os-logo.{png|svg} or so
instead, i.e. standardize the name and expect the same search path
logic as for /{usr/lib|etc}/os-release itself.
3. A "named icon" according to the icon naming/theming specs?
[https://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html
and
https://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html]
(this would solve the resolution problem, but maybe might be a bit
overkill, a logo is not an icon after all, and "themed logos" are a
weird concept...)
Maybe a combination of option 3 and the os-logo.{png|svg} idea could
work, so that downstreams can choose whether they want the
comprehensive solution or the easy and slightly sloppy one.

I think 3 makes most sense, every desktop / toolkit has code for
handling fdo icons. 1 would be less then optimal given every desktop
will want to use it in a different size, enlightenment for example would
want 40px on its default shelf but a user could customize it to be as
small as 16 and on a high dpi display it could be substantially larger,
fdo already covers separate icons for those cases or svg. At the same
time i could see uses for it in certain dialogs at 256px.

I can't think of a common case where an image path would be easier then
a fdo icon. Other then obscure things like the terminology terminal
emulator supports inlining images so you could embed the distro icon as
part of a login welcome message.