Expand os-release spec with LOGO

[Simon Lees]

On 08/10/2018 20:07, Lennart Poettering wrote:
> On So, 07.10.18 15:39, hellcp at opensuse.org (hellcp at opensuse.org) wrote:
> 
>> 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.
> 

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.

-- 

Simon Lees (Simotek)                            http://simotek.net

Emergency Update Team                           keybase.io/simotek
SUSE Linux                           Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20181011/dbfa960d/attachment.sig>