On 08/10/2018 20:07, Lennart Poettering wrote: > On So, 07.10.18 15:39, hel...@opensuse.org (hel...@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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg