CC @pnemade @mfabian, perhaps you could get some help from Jakub to replace the icon?

Please see https://gitlab.gnome.org/Teams/Design/library-icons/-/commit/d8bc62c3c9827b4b59bd2dcb4b67c6eed17d1104 where Jakub provided a symbolic icon for ibus/input methods

For example:
https://gitlab.gnome.org/Teams/Design/library-icons/-/blob/d8bc62c3c9827b4b59bd2dcb4b67c6eed17d1104/library-icons/ibus-r.svg

Also, this component is being flagged as potentially unsafe and the author name doesn't help to indicate that this is a system component.

That might be because you installed it from my copr repo, not from the Fedora rpm

If somebody draws a nice icon, I’ll replace it.

The current icon is the upstream logo of the m17n project:

https://www.nongnu.org/m17n/

Given that this only affects the copr repo currently I think we could close this.

But what about the icon?

I don't have the copr repo enabled:

But what about the icon?

@mfabian The 3rd answer has an icon suggest.

But what about the icon?

@mfabian The 3rd answer has an icon suggest.

That is a generic icon which does not relate to ibus-m17n or m17n in any way.

I don't have the copr repo enabled:

If you don’t have the copr repo installed but it still shows as “potentially unsafe” then this must be either some bug in gnome-software in displaying this or it suddenly wants a different way to spell the license?

https://github.com/ibus/ibus-m17n/blob/main/m17n.appdata.xml

currently has: GPL-2

and the ibus-m17n.spec file

https://src.fedoraproject.org/rpms/ibus-m17n/blob/rawhide/f/ibus-m17n.spec

has:

License: GPLv2+

Which apparently was OK for me because I did not see that warning unless using the package from the copr repo.

But maybe the SPDX format is required now?

https://spdx.org/licenses/preview/

has:

GPL-2.0-or-later

@mfabian

When I open the source chooser, nothing appears. I have Fedora 36 Workstation installed in a VM which has the same behavior:

Potentially unsafe message:

What about using this cog icon that ibus-hangul uses? @mfabian

After updating to F37, iBus-M17N is marked as safe and the source chooser is working again:

What about using this cog icon that ibus-hangul uses? @mfabian

That cog is just the default fallback for not setting an icon at all.

It is nicer if the different programs have different icons and not all the same.

The “ugly” parrot is actually the upstream logo for the m17n library. m17n is a multilingulization library, parrots is known for “speaking”, so I think a parrot is a nice choice actually.

Maybe a more beautiful picture of a parrot would be good.

I don't think that it makes sense to have user-facing brand identities for the input methods. As an alternative, GNOME Software includes a set of icons for system components:

• system-component-addon
• system-component-application
• system-component-driver
• system-component-firmware
• system-component-input-sources
• system-component-language
• system-component-on-updates
• system-component-runtime

The types of software that are covered by these icons need to use them, in order to have consistent graphics in the updates list.

In the past we've tracked issues where input sources haven't been using these icons, such as gnome-software#1483.

What is the next step for this issue?

So I see it is no longer being displayed as "potentially unsafe" but the bad icon is still there:

Probably all we need to do is remove the icon from the appstream metainfo, so Software will use system-component-input-sources instead? Hi @mcrha, do you agree that is what we should do here? It's not a problem for the input method to not specify an icon, right?

You can see what the changes in the appdata do with: gnome-software --show-metainfo=/tmp/m17n.appdata.xml . The both icons can be removed from the appdata, then it'll receive some default icon. Note the appstream-data package can add its own icons, it depends how that thing is generated.

A side note, typing booster has its own icon too, it's only colorful.

One thing, on f37, the /usr/share/metainfo/m17n.appdata.xml references these icons:

  <icon type="remote" width="128" height="128">https://raw.githubusercontent.com/ibus/ibus-m17n/main/icons/128x128/ibus-m17n.png</icon>
  <icon type="remote" width="256" height="256">https://raw.githubusercontent.com/ibus/ibus-m17n/main/icons/256x256/ibus-m17n.png</icon>

None of them look like the icon shown on the screenshot. When I cleanup my local icon cache (.cache/gnome-software/icons), then when I restart the gnome-software and then open the m17n, it shows the colorful parrot. It looks quite good, to be honest.

The parrot is a much better icon, indeed.

How frequently does gnome-software clean its icon cache? Hopefully it doesn't keep the old icon around forever, but expires them eventually? It may be that's the only problem remaining here.

I briefly looked into the gnome-software code and if I read it correctly the icon cache never expires.

Having the URI changed, not only the content of it, the new icon would be picked immediately. Though that's not a problem here.

Feel free to file a bug in the gnome-software upstream.

Wouldn’t it be better to download the remote icons always if possible and only fallback on the icon cache if the download is not possible?

No, if you care of the bandwidth use and speed of the app. For example my ~/.cache/gnome-software/icons currently contains 946 files. There had been also a problem with slow Categories page load in the Software, possibly just due to the load of the remote icons (I cannot tell for sure in what state it is right now). Thus no, the cache is preferred for a good reason.

Reported https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2005 to fix the caching problem. I think that's the only remaining work here, so closing.

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/workstation/tickets/issues/333

Please continue any further discussion there.