Created attachment 853726 [details]
GNOME 40 info

Created attachment 853727 [details]
GNOME 41 info

I guess the LOGO var in /usr/lib/os-release changed so it cannot find logo in /usr/share/pixmaps/distributor-logos, will look at it.

@Alynx: the change was in g-c-c, how it finds the logo. I had only invested a few minutes on it at the very beginning (strace showed the right file would be found)

Relevant upstream change should be
https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/985

(In reply to Dominique Leuenberger from comment #4)
> @Alynx: the change was in g-c-c, how it finds the logo. I had only invested
> a few minutes on it at the very beginning (strace showed the right file
> would be found)
> 
> Relevant upstream change should be
> https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/985

I've read the code, and it should behave the same because we don't have -text or -text-dark logos. Both version 40 and version 41 will load the LOGO var in /usr/lib/os-release under /usr/share/pixmaps/, so I think there should be changes in those two packages.

Also I think the current used code is from commit 43b40b3b4a18a37cb3741179bf0b627f535731b4, which fixed problem in https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/985.

Or there might be some difference between gtk_image_set_from_icon_name and g_themed_icon_new_from_names, like searching path...

> grep LOGO /usr/lib/os-release 
LOGO="distributor-logo-Tumbleweed"

(this is unchanged for a while)

> strace gnome-control-center 2>&1 | grep distributor-logo
openat(AT_FDCWD, "/usr/share/icons/hicolor/scalable/apps/distributor-logo-Tumbleweed.svg", O_RDONLY) = 19

and /usr/share/icons/hicolor/scalable/apps/distributor-logo-Tumbleweed.svg does show the proper TW logo (transparent background)

(In reply to Dominique Leuenberger from comment #8)
> > grep LOGO /usr/lib/os-release 
> LOGO="distributor-logo-Tumbleweed"
> 
> (this is unchanged for a while)
> 
> > strace gnome-control-center 2>&1 | grep distributor-logo
> openat(AT_FDCWD,
> "/usr/share/icons/hicolor/scalable/apps/distributor-logo-Tumbleweed.svg",
> O_RDONLY) = 19
> 
> and /usr/share/icons/hicolor/scalable/apps/distributor-logo-Tumbleweed.svg
> does show the proper TW logo (transparent background)

That is strange, I run strace gnome-control-center 2>&1 | grep distributor-logo and got no output on new installed tumbleweed

My newly installed Tumbleweed does not have /usr/share/icons/hicolor/scalable/apps/distributor-logo-Tumbleweed.svg, strange...

$ zypper se distribution-logos-openSUSE
Loading repository data...
Reading installed packages...

S | Name                                   | Summary                   | Type
--+----------------------------------------+---------------------------+--------
  | distribution-logos-openSUSE            | Logos for openSUSE Dist-> | package
  | distribution-logos-openSUSE-Kubic      | Logos for openSUSE Kubic  | package
  | distribution-logos-openSUSE-MicroOS    | Logos for openSUSE Micr-> | package
i | distribution-logos-openSUSE-Tumbleweed | Logos for openSUSE Tumb-> | package
  | distribution-logos-openSUSE-icons      | Icons with distribution-> | package

Looks like we don't have distribution-logos-openSUSE-icons installed by default on Tumbleweed? Files under /usr/share/icons/hicolor/ is in this package.

Created attachment 853848 [details]
strace result

It seems that g-c-c has found the logo svg file, but can't show in the panel correctly.

It seems GIcon can load svg under /usr/share/pixmaps/ correctly but not /usr/share/icons/hicolor/scalable/apps/, I write a small program to load logo on my own machine (even not opensuse), and if I put the tumbleweed svg in /usr/share/pixmaps/, it works, but put svg in /usr/share/icons/hicolor/scalable/apps/, a warning logo is shown.

Created attachment 853907 [details]
/usr/share/pixmaps/ works fine

Created attachment 853908 [details]
/usr/share/icons/hicolor/scalable/apps/ opened but not rendered

I'd like to check icon loading code next.

Some interesting find:

If I move distributor-logo-Tumbleweed.svg to /usr/share/icons/Adwaita/scalable/apps, a missing-logo is shown, but it turns out that you need to run `sudo gtk-update-icon-cache /usr/share/icons/Adwaita/` and `sudo gtk-update-icon-cache /usr/share/icons/hicolor/` to rebuild the cache, then the logo shows correctly.

And if I move the logo back to hicolor and run `sudo gtk-update-icon-cache /usr/share/icons/Adwaita/` and `sudo gtk-update-icon-cache /usr/share/icons/hicolor/`, no logo is shown (even the missing logo), every thing seems working fine but no logo, I guess maybe the size is wrongly calculate to 0 (but not sure).

Still reading code.

So I think the problem actually happens here: https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gtk/gtkicontheme.c#L3958

I managed to print the `size` var, and find something interesting:

If put svg in pixmaps, size is 0, so it will load svg with desired_size, which should be a proper value and you can see the icon.

If put svg in Adwaita, size is 8, it's small but you still can see the icon.

If put svg in hicolor, size is 1 (???!!!), so the icon is too small to see it.

I'll read more code to see where those numbers come and fix it.

So finally it turns out a big mess, every code pieces have a proper logic and when they works together they lead into a joke.

We have GtkImage before we load icon, so we cannot decide GtkImage's size and we want the icon to decide its size so we pass GTK_ICON_SIZE_INVALID.

But GtkIconHelper treat GTK_ICON_SIZE_INVALID as 0 (https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gtk/gtkiconhelper.c#L238), so it loads icon with size == 0.

And after a mess of functions we reached https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gtk/gtkicontheme.c#L3958, because we put logo under hicolor theme, so it's size is decided by theme's size.

And theme's size is calculated in https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gtk/gtkicontheme.c#L3081, where it compares GtkIconHelper's size (0) with theme icons' size and uses the one with minimal difference, for scalable icons, we have

```
[scalable/apps]
MinSize=1
Size=128
MaxSize=256
Context=Applications
Type=Scalable
```

so the nearest value to 0 is 1, so finally we got a 1px logo which cannot be seen...

For Adwaita, the MinSize is 8, which is also too small, but at lease we can see it.

You can try to modify /usr/share/icons/hicolor/index.theme to make MinSize=16, and update icon cache, then you will see the logo in gnome-control-center (but 16 is too small though).

I am not sure where to fix it, passing GTK_ICON_SIZE_INVALID is ok here, and I am not sure if changing https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gtk/gtkiconhelper.c#L238 to bigger value is OK, and it's hard to decide a better MinSize for hicolor...

Created attachment 854039 [details]
After change MinSize to 16

GNOME 40 is fine is because that upstream manually set GtkImage's size before GNOME 41 (https://gitlab.gnome.org/GNOME/gnome-control-center/-/commit/fdd629293d25adc7f44031ad9eab4c6a5589b005), which covers this bug.

However revert this commit seems not a proper fix, it's just a workaround, and upstream wants to support non-square logo.

so it sounds like we should move the ./hicolor/scalable/apps/distributor-logo-Tumbleweed.svg to /usr/share/pixmap and be done with it

The icon theme overriding a distro logo sounds very debatable anyway, so the change very likely is correct anyway

Do you see any reason NOT to move the distributor-logos to /usr/share/pixmaps? They don't really have any relevance to an icon theme

(In reply to Dominique Leuenberger from comment #23)
> Do you see any reason NOT to move the distributor-logos to
> /usr/share/pixmaps? They don't really have any relevance to an icon theme

I think /usr/share/pixmaps should be the better please for distribution logo, I am also confused that why we put it under hicolor, move it is reasonable for me.

But I still want to fix it in the Gtk side (or maybe hicolor) too, where the problem actually exists.

(In reply to Alynx Zhou from comment #24)

> But I still want to fix it in the Gtk side (or maybe hicolor) too, where the
> problem actually exists.

I mean the 1px problem when we want gtk to decide the best icon size. Not related to the logo location.

I opened an upstream issue for icon size:
https://gitlab.gnome.org/GNOME/gtk/-/issues/4488

Adding Richard to cc/needinfo since he had a hand in the logo package too.

Fixed in GNOME:Next - with GNOME 42.
https://openqa.opensuse.org/tests/2245673#step/gnome_control_center/9

Will trickle down to Tumbleweed as GNOME 42 gets ready.