After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 695691 - Details should show distro logo and version, not GNOME
Details should show distro logo and version, not GNOME
Status: RESOLVED OBSOLETE
Product: gnome-control-center
Classification: Core
Component: general
3.7.x
Other Linux
: Normal normal
: ---
Assigned To: Control-Center Maintainers
Control-Center Maintainers
triaged
: 792819 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-03-12 10:45 UTC by Allan Day
Modified: 2021-06-09 16:27 UTC
See Also:
GNOME target: ---
GNOME version: 3.23/3.24


Attachments
info: Switch around GNOME and distro information (3.07 KB, patch)
2013-04-01 00:38 UTC, Matthias Clasen
none Details | Review
info: Switch around GNOME and distro information (3.07 KB, patch)
2013-05-03 12:51 UTC, Ondrej Holy
none Details | Review
screenshot with fedora logo (42.25 KB, image/png)
2013-05-03 12:52 UTC, Ondrej Holy
  Details
info: Switch around GNOME and distro information (13.93 KB, patch)
2013-05-03 15:23 UTC, Ondrej Holy
needs-work Details | Review
screenshot with fedora logo (41.20 KB, image/png)
2013-05-03 15:24 UTC, Ondrej Holy
  Details

Description Allan Day 2013-03-12 10:45:08 UTC
Many users won't know what GNOME is, and will think of their system as being their distro. Showing "GNOME, Version 3.6.2" won't mean very much to them. It also diminishes the brand identity of the distro.

We should show the distro logo and version here instead of GNOME. If the GNOME version is required for debugging or error reporting it could be added as a smaller string below.
Comment 1 Matthias Clasen 2013-03-26 13:16:39 UTC
Allan, to clarify:

We would replace the gnome logo with the distro logo, and put the string that we currently have as 'Base System' in the place where we currently say 'Version 3.8.0'. Right ?
Comment 2 Bastien Nocera 2013-03-26 14:50:31 UTC
As discussed with Matthias, I don't think it's GNOME's job to handle the distro's brand identity, even if they are currently our primary distributors.

I think this would be nicely handled downstream by a distro patch.

See also bug 688957
Comment 3 Matthias Clasen 2013-04-01 00:38:18 UTC
Created attachment 240273 [details] [review]
info: Switch around GNOME and distro information

This makes the distribution logo prominent, and puts GNOME version
information in the small print.
Comment 4 Jeremy Bicha 2013-04-01 01:17:25 UTC
Review of attachment 240273 [details] [review]:

::: panels/info/info.ui
@@ +244,3 @@
                                 <property name="visible">True</property>
                                 <property name="can_focus">False</property>
+                                <property name="pixbuf">/usr/share/icons/Fedora/scalable/places/start-here.svg</property>

Can't you just use 'start-here' or 'start-here.svg' as the icon name so that every distro won't be required to patch this?
Comment 5 Bastien Nocera 2013-04-01 10:53:13 UTC
(In reply to comment #4)
<snip>
> Can't you just use 'start-here' or 'start-here.svg' as the icon name so that
> every distro won't be required to patch this?

Can we please drop the passive aggressiveness?

It's a downstream patch, and the patch is posted here as a courtesy.
Comment 6 Allan Day 2013-04-26 08:53:58 UTC
(In reply to comment #5)
> It's a downstream patch, and the patch is posted here as a courtesy.

I'd be interested to know why we are recommending that distros patch this, actually. There are a lot of smaller organisations that do their own internal rebrandings of GNOME.
Comment 7 Ondrej Holy 2013-05-03 12:51:53 UTC
Created attachment 243179 [details] [review]
info: Switch around GNOME and distro information

There is slightly modified patch without absolute path and with reduced icon size.
Comment 8 Ondrej Holy 2013-05-03 12:52:43 UTC
Created attachment 243180 [details]
screenshot with fedora logo
Comment 9 Ondrej Holy 2013-05-03 15:23:35 UTC
Created attachment 243200 [details] [review]
info: Switch around GNOME and distro information

Slightly design changes. Using NAME and VERSION instead of PRETTY_NAME. Added "OS Type" column.
Comment 10 Ondrej Holy 2013-05-03 15:24:11 UTC
Created attachment 243201 [details]
screenshot with fedora logo
Comment 11 Bastien Nocera 2016-11-08 13:34:07 UTC
3 years later, we might want to consider some of those changes upstream, to avoid more egregious attempts at branding.

Portions of this are already in:
https://bugzilla.gnome.org/show_bug.cgi?id=770593
Comment 12 Michael Catanzaro 2016-11-08 15:54:20 UTC
(In reply to Bastien Nocera from comment #11)
> 3 years later, we might want to consider some of those changes upstream, to
> avoid more egregious attempts at branding.

I agree that we should upstream this. There's no value in keeping this downstream forever. Distributions that don't set a logo should continue to receive the GNOME foot, of course.
Comment 13 Georges Basile Stavracas Neto 2018-01-21 14:23:48 UTC
Review of attachment 243200 [details] [review]:

Thanks for the patch. If this is the direction we want to take, I'll accept the patch, but it needs to be rebased against master.
Comment 14 Allan Day 2018-01-22 12:56:47 UTC
(In reply to Georges Basile Stavracas Neto from comment #13)
...
> ... If this is the direction we want to take,

From a design perspective, we generally try not to expose the concept of "GNOME" and instead refer to the distro - so from that perspective, it is the direction we want to take.
Comment 15 Mario Sánchez Prada 2018-01-23 12:13:58 UTC
I just filed bug 792819 today without realizing this one was filed already (thanks Jeremy for pointing it out) and I agree it could be worth merging the two bugs in one since they seem to help solving the same problem, although I'll leave the patch attached there for now in case we want to keep it separate.

@Georges, others: could you please take a look to that bug + the patch attached and let me know what makes most sense to you? Thanks!
Comment 16 Georges Basile Stavracas Neto 2018-01-23 15:41:17 UTC
Let's track the discussion that was happening in 792819 here. Bastien's comment was:

"As discussed on IRC, I think the easiest way to implement this would be to have a parameter for the logo name added to systemd's os-release file, similarly to:
https://github.com/systemd/systemd/commit/ed9e8bf66d1b3a00aa7fb6d57ec89dd8a3b8d7dc

And have the code show the gnome logo if absent, and the gnome version instead of the os version if /etc/os-release is missing. Note that if a distro/os version is available, we'd want to show the GNOME version separately."

Mario replied with:

"In any case, I think such mechanism would work too, although I'd say it would be still nice that there were a mechanism to include a way to specify the name (or path) to a image file explicitly, instead of simply deriving it from the ID rightaway, for greater flexibility.

If no logo name/file is explicitly set, then I guess it could be derived from the ID, finally falling back to the GNOME logo if nothing is found."
Comment 17 Bastien Nocera 2018-01-23 15:45:50 UTC
(In reply to Georges Basile Stavracas Neto from comment #16)
<snip>
> "In any case, I think such mechanism would work too, although I'd say it
> would be still nice that there were a mechanism to include a way to specify
> the name (or path) to a image file explicitly, instead of simply deriving it
> from the ID rightaway, for greater flexibility.

What "ID"?

> If no logo name/file is explicitly set, then I guess it could be derived
> from the ID, finally falling back to the GNOME logo if nothing is found."

What's the use for this multi-layer system, really? Show distro info if it's there, otherwise show GNOME seems simple enough.
Comment 18 Mario Sánchez Prada 2018-01-23 16:00:50 UTC
(In reply to Bastien Nocera from comment #17)
> (In reply to Georges Basile Stavracas Neto from comment #16)
> <snip>
> > "In any case, I think such mechanism would work too, although I'd say it
> > would be still nice that there were a mechanism to include a way to specify
> > the name (or path) to a image file explicitly, instead of simply deriving it
> > from the ID rightaway, for greater flexibility.
> 
> What "ID"?

The one present in the os-release file (see [1])

> > If no logo name/file is explicitly set, then I guess it could be derived
> > from the ID, finally falling back to the GNOME logo if nothing is found."
> 
> What's the use for this multi-layer system, really? Show distro info if it's
> there, otherwise show GNOME seems simple enough.

I think I might have misunderstood the idea, for some reason I thought generating the filename out of fields such as ID was in the plan, but maybe I was wrong.

In any case, let me expose the need with an example. At the moment these are the contents of my os-release file:

  $ cat /etc/os-release
  NAME="Endless"
  VERSION="3.4.0"
  ID="endless"
  ID_LIKE="ubuntu debian"
  PRETTY_NAME="Endless 3.4.0"
  VERSION_ID="3.4.0"
  HOME_URL="http://www.endlessm.com/"


What I meant with my comment is that it could nice to have a way to specify, explicitly, the name of the image file instead of simply generating it out of the fields in there, since it could be that different deployments of the same OS (I'm thinking of Endless here) shared the same values for ID and NAME.

From what I can read in [2], that seems to be the idea behind adding the new "LOGO" field to os-release, so I guess we're good. I was just trying to make the point that such explicit field was a good idea instead of simply generating things from fields like ID, but if that was never the case then forget anything I said.

The only concern I have with that approach is that it might be sane to prefix that new field and have something like "GNOME_LOGO" instead of simply "LOGO", as recommended in [1]: 

  """
  Operating system vendors may extend the file format and introduce new fields. It is highly
  recommended to prefix new fields with an OS specific name in order to avoid name clashes.
  """

In any case, it seem like you are all already pretty focused on getting this working and that such solution will be good, so I'll get out of the way and stop making noise :-)

[1] https://www.freedesktop.org/software/systemd/man/os-release.html
[2] https://bugzilla.gnome.org/show_bug.cgi?id=792819#c6
Comment 19 Bastien Nocera 2018-01-23 16:44:06 UTC
I'd add a LOGO=, which can either be a "named-icon" (link to fd.o icon theme spec), or a full path to a file, to /etc/os-release.
Comment 20 Jeremy Bicha 2018-01-23 16:45:03 UTC
*** Bug 792819 has been marked as a duplicate of this bug. ***
Comment 21 Jeremy Bicha 2018-01-23 16:46:54 UTC
I'm copying my comment from the duplicate bug 792819

I assume we want logo to be just an icon name without an extension (like 'fedora-logo') instead of an absolute path. That way, a client app could possibly easily use a symbolic version of the icon if available.

By the way, GDM offers a distro logo option and that's a popular feature among distros (Debian enables it for instance). The GDM distro logo is often white and there is room for it to be horizontal. (Fedora and Ubuntu use a simple circle logo in their gnome-control-center patches.)

So I'm thinking it might make sense to have at least the 2 variants in /etc/os-release: square and rectangle (or whatever the terminology is for those).
Comment 22 Jeremy Bicha 2018-05-10 17:05:03 UTC
(In reply to Bastien Nocera from comment #19)
> I'd add a LOGO=, which can either be a "named-icon" (link to fd.o icon theme
> spec), or a full path to a file, to /etc/os-release.

Ping! I looked but I don't think this has been done yet.
Comment 23 Michael Catanzaro 2020-03-12 21:58:49 UTC
We still haven't completed Bugzilla migration for g-c-c...?

(In reply to Jeremy Bicha from comment #22)
> Ping! I looked but I don't think this has been done yet.

LOGO is now documented at https://www.freedesktop.org/software/systemd/man/os-release.html.
Only problem is that it turns out distros have multiple versions of different logos, and Fedora now has a requirement to display a different logo than the one that we have included in /etc/os-release: https://pagure.io/fedora-workstation/issue/135.

I think I want to use Mario's patch from bug #792819. Bastien, thoughts?
Comment 24 Bastien Nocera 2020-03-13 09:29:47 UTC
I have no idea what comment you'd want from me. If there's a patch, it's unlikely to apply correctly anymore now that the panel has been redesigned. This should probably be closed and any discussion restarted on gitlab.
Comment 25 Bastien Nocera 2020-03-13 12:31:18 UTC
(In reply to Michael Catanzaro from comment #23)
> We still haven't completed Bugzilla migration for g-c-c...?
> 
> (In reply to Jeremy Bicha from comment #22)
> > Ping! I looked but I don't think this has been done yet.
> 
> LOGO is now documented at
> https://www.freedesktop.org/software/systemd/man/os-release.html.
> Only problem is that it turns out distros have multiple versions of
> different logos, and Fedora now has a requirement to display a different
> logo than the one that we have included in /etc/os-release:
> https://pagure.io/fedora-workstation/issue/135.
> 
> I think I want to use Mario's patch from bug #792819. Bastien, thoughts?

I've finally been able to understand what this question was about.

I don't think we want gnome-control-center to have a separate configuration option for the logo, so Mario's patch (even updated for meson, etc.) isn't something we'd entertain.

If we (GNOME) want the vendor logo in this position (upstream), then a patch will need to be written, and Fedora will need to make sure the logo in /etc/os-release is the one it wants used.

For now, the logo in Fedora is changed through a downstream patch that will need changing if you want that changed quickly.
Comment 26 Michael Catanzaro 2020-03-13 13:02:30 UTC
Problem is, if anything else is actually relying on the logo we have in /etc/os-release, we probably don't want to change the version of the logo that we're using there. I'll just modify our downstream patch to hardcode the new logo if you don't want to add a vendor.conf file.
Comment 27 Bastien Nocera 2020-03-13 13:15:54 UTC
(In reply to Michael Catanzaro from comment #26)
> Problem is, if anything else is actually relying on the logo we have in
> /etc/os-release, we probably don't want to change the version of the logo
> that we're using there. I'll just modify our downstream patch to hardcode
> the new logo if you don't want to add a vendor.conf file.

Then /etc/os-release can be further extended... I don't think that it's particularly helpful to get a LOGO field added to os-release to then not use it.

If you _really_ need to, g-c-c could append "-versioned" to the icon name fetched from os-release, which would automatically fallback to the name in os-release if the -versioned variant didn't exist.

But there aren't any applicable patches to show the vendor logo yet, so starting with that would probably be a good idea.
Comment 29 André Klapper 2021-06-09 16:27:11 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new bug report at
  https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/

Thank you for your understanding and your help.