Missing icon and app name in the dash of Gnome Shell

[Digitalone1]

Is there an existing issue for this?

• I have searched the existing issues.

What's the problem?

As shown in the screenshot. Usually this issue is resolved specifying StartupWMClass in the .desktop file. Tried it, but nothing changes.

Maybe an issue related to iced library. I don't know. Should be investigated.

How did you install the app?

downloaded one of the provided packages

Operating System

Linux

Additional context

https://archlinux.org/packages/extra/x86_64/sniffnet/

[Digitalone1]

Making some researches I found out these:

• Gnome wmclass is null in Wayland rust-windowing/glutin#1067
• Introduce WindowBuilderExt::with_app_id for wayland rust-windowing/winit#700
• https://developer.gnome.org/documentation/tutorials/application-id.html

TLDR: The app needs an id in Wayland. Maybe it's not set and this causes the issue? The question is whether iced has a way to set it.

[Digitalone1]

Maybe the id here, but I don't know if it's already specified.

[GyulyVGC]

Mm, it's not a problem related to iced.

The icon displays just fine in the Debian based and Red Hat based distros (see here the corresponding files: https://github.com/GyulyVGC/sniffnet/tree/main/resources/packaging/linux).

I didn't personally packages it for Arch Linux.
Maybe @orhun, the package maintainer, can tell you more about this, as I think the problem could reside in how the app was packaged for Arch.

[Digitalone1]

Did you test on Gnome Wayland?

[Digitalone1]

Look, I replaced the content of this desktop file (the custom Arch one uses the keyword key and different categories).

Even tried to reboot the system, but the icon is still not showing.

I don't think the package is built in a different way you normally do. You can see here: https://gitlab.archlinux.org/archlinux/packaging/packages/sniffnet/-/blob/main/PKGBUILD#L26-43

I don't know what this post install is doing: https://gitlab.archlinux.org/archlinux/packaging/packages/sniffnet/-/blob/main/sniffnet.install

setcap cap_net_raw,cap_net_admin=eip usr/bin/sniffnet

But I don't think it's related to the menu.

I can confirm, at least on Gnome Wayland 44, the dash can't see the name of the application and its icon.

[GyulyVGC]

Did you test on Gnome Wayland?

Nope

I don't know what this post install is doing: https://gitlab.archlinux.org/archlinux/packaging/packages/sniffnet/-/blob/main/sniffnet.install

setcap cap_net_raw,cap_net_admin=eip usr/bin/sniffnet

But I don't think it's related to the menu.

It has nothing to do with icons, that script just sets the capabilities to inspect a network adapter.

I can confirm, at least on Gnome Wayland 44, the dash can't see the name of the application and its icon.

I'm not able to try the app on Gnome Wayland right now, so I cannot troubleshoot it at the moment.
Luckily it's a minor usability issue, but if you discover something new please let me know.

[Digitalone1]

I'm not able to try the app on Gnome Wayland right now, so I cannot troubleshoot it at the moment. Luckily it's a minor usability issue, but if you discover something new please let me know.

As I pointed out, this issue could be resolved setting an app_id.

Unfortunately I'm not expert with Rust, otherwise I would have tried to test the library. Anyway, can you try to set an app id?

Should be the id property here of the Settings structure attached to the window instance: https://docs.rs/iced/latest/iced/settings/struct.Settings.html

Winit has this method to set it: https://github.com/elinorbgr/winit/blob/5643865387d805ae7557af2c491deafe11ce97fa/src/os/unix.rs#L229-L234

Should be something similar for iced.

[GyulyVGC]

Sure, I will set that field to "sniffnet".
I will ping you at the next release to know if it's enough to solve the issue.

[Digitalone1]

Sure, I will set that field to "sniffnet". I will ping you at the next release to know if it's enough to solve the issue.

Is there a way to test the application without installing the build files under /usr/? So I can test soon after you make the commit, without waiting for the next release.

Arch package is built with cargo build --frozen --release and it seems to build the executable under ``target/release/sniffnet`. Can you confirm? Sorry if I'm not an expert, the only builds I tested are for C++ apps.

[GyulyVGC]

Done.
Oh sure, if you have Rust installed you can clone the repo and build yourself with cargo build --release (I've never used the --frozen flag).
The executable will be in the directory you mentioned.
Then you can move that executable in usr/bin to test the behaviour.

[Digitalone1]

Nice. That was the cause of the issue. Resolved.

[GyulyVGC]

Wow, thank you so much for having let me know about that id field 🥇

[GyulyVGC]

@all-contributors please add @Digitalone1 for bug.

[allcontributors]

@GyulyVGC

I've put up a pull request to add @Digitalone1! 🎉

[orhun]

Hey, I'm a bit late to the party but I guess the problem is resolved with the mentioned commit. Either way, let me know if you need anything else on the Arch packaging side!

[GyulyVGC]

No worries, the problem is solved and was not due to the package.
Thanks anyway 🙏

[Digitalone1]

Hey, I'm a bit late to the party but I guess the problem is resolved with the mentioned commit. Either way, let me know if you need anything else on the Arch packaging side!

I filed a bug report on Arch. Please use the desktop file reported here. It's safer and it uses the StartupWMClass keyword.

[GyulyVGC]

Oh, I didn't get that with the original Arch .desktop and the app id property set it still don't work

[Digitalone1]

Oh, I didn't get that with the original Arch .desktop and the app id property set it still don't work

I'm using the desktop file reported here and it works with the latest master. Don't know for the Arch one but the wm class should be specified anyway. I noticed for other applications that if it does not match the app id, the name is not shown on the Dash.

[Digitalone1]

Oops, I only took a look at the Dash. But now that I try to analyze the traffic, it shows the following with the latest master:

I copied the build in /usr/bin/sniffnet. The application is launched from the menu.

[GyulyVGC]

That's because you have to run that post installation script (or run in sudo mode)

[Digitalone1]

That's because you have to run that post installation script (or run in sudo mode)

Ok, I got it.

[orhun]

Updated the Arch package with suggested changes, thanks!

[Digitalone1]

I'm afraid this has to be reopened because I restarted to use sniffnet, but I don't see the proper app icon on the Gnome Dash.

I remember that it was correctly visible after setting the id in the code, but now it disappeared again. Maybe another iced issue, I don't know.

Unfortunately I returned to use iftop. It's on the command line and it misses the flags, but at least it gives me less headaches than sniffnet on Gnome Linux.

[GyulyVGC]

It could be related to the migration to iced 0.10.

They introduced a further configuration for the app id and I think that this could be solution: iced-rs/iced#1963

[GyulyVGC]

I've just pushed the fix to the main branch.
Let me know if it solves the problem when you can.

[Digitalone1]

I've just pushed the fix to the main branch. Let me know if it solves the problem when you can.

Thanks for you effort. So I tried two ways:

1. The first sunning the compiled build directly from the command line, but the issue is still there:

2. The second, I reinstalled sniffnet from Arch upstream and replaced the compiled build in /usr/bin/sniffnet. This solves the issue:

So, in order to see the icon, the build should have the sniffnet id set like in 19957dc and the application should be launched by the desktop entry having the StartupWMClass=sniffnet key set here.

Thanks @GyulyVGC

[GyulyVGC]

Perfect, no problem!

Ps: I've also started adding advanced settings in a secondary branch and soon an option to change the report location will be included! (To be released in v1.3 as already discussed)