Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

The opened application should be recognised as a dangerzone by Fedora 38 with GNOME Desktop #402

Closed
sudwhiwdh opened this issue Apr 28, 2023 · 7 comments
Closed

The opened application should be recognised as a dangerzone by Fedora 38 with GNOME Desktop #402

sudwhiwdh opened this issue Apr 28, 2023 · 7 comments
Labels
bug Something isn't working good first issue Good for newcomers P:linux

Comments

@sudwhiwdh
Copy link
Contributor

sudwhiwdh commented Apr 28, 2023 •
edited
Loading

02
07
01

Instead, python3 is displayed in various places (here Dock, Panel, Window Overview)

My wish would be that "dangerzone" is displayed together with the appropriate application icon.
@apyrgio
Copy link
Contributor

apyrgio commented May 10, 2023

Right, I can reproduce this locally, but I never managed to dig deeper. Our .desktop file uses the "dangerzone" name everywhere, so maybe we are missing a field that Gnome understands.

@apyrgio apyrgio added bug Something isn't working good first issue Good for newcomers P:linux labels May 10, 2023
@sudwhiwdh
Copy link
Contributor Author

@apyrgio Is still present in version 0.4.2.

@apyrgio
Copy link
Contributor

apyrgio commented Aug 24, 2023

Sigh, it most probably is, since we haven't found the time to work on it. It's one of these issues that are not bugs or new features, so they stay for a bit more in the back burner. I have tagged it as good first issue though, and I encourage newcomers that want to assist in Dangerzone's development to take a stab at it.

@apyrgio apyrgio mentioned this issue Sep 11, 2023
Merged
@deeplow
Copy link
Contributor

deeplow commented Sep 19, 2023

This issue will probably be a bit about finding the proper directory to install the desktop icon.

Here's a section of a related discussion:

The location you're seeing is the one where we previously installed this icon. You're right for pointing this out, and I think this may affect #402. Still, I'd suggest tackling it in a different PR, if you don't mind, since I bet we will go into a rabbit hole.

@apyrgio
Copy link
Contributor

apyrgio commented Dec 7, 2023

We are still bitten by this as @deeplow found out in our recent QA for 0.5.1 (#634 (comment)). Apologies, and I hope we can have a fix out in time.

@sudwhiwdh sudwhiwdh mentioned this issue Jan 16, 2024
Closed
naglis added a commit to naglis/dangerzone that referenced this issue Apr 9, 2024
@naglis
Set the desktop filename of the Qt application
993f0b5 
Currently, the app ID of the Dangerzone GUI application when running
under Wayland is `python3`, which is not very useful if one wants to
automate some action related to the Dangerzone application window (e.g.
to always start Dangerzone window in floating mode under Sway WM).

Setting the desktop filename property also sets the app ID of the
application under Wayland. According to Qt documentation[1], the
property value should be the name of the application's .desktop file but
without the extension.

Qt documentation also states:

> This property gives a precise indication of what desktop entry
> represents the application and it is needed by the windowing system to
> retrieve such information without resorting to imprecise heuristics.

Therefore I also think that setting this property is needed to display
the correct application name and icon (taken from the .desktop entry)
when running under certain windowing systems (like Wayland)
(see also freedomofpress#402).

[1]: https://doc.qt.io/qt-6/qguiapplication.html#desktopFileName-prop
@naglis naglis mentioned this issue Apr 9, 2024
Merged
@apyrgio
Copy link
Contributor

apyrgio commented Apr 25, 2024

I think we have a fix here, which I've verified it works in Fedora 39 (see #774). If we set in our application:

self.setDesktopFileName("press.freedom.dangerzone")
self.setApplicationName("dangerzone")

then the correct icon, application ID, and name, is reported as well. Depending on the OS, only the desktop file name may be needed, but we want to set both to leave no room for ambiguity.

@apyrgio
Copy link
Contributor

apyrgio commented Apr 25, 2024

The fix has just been merged in main, and will be available in 0.6.1. If you still encounter an issue in your OSes, we'll reopen it.

@apyrgio apyrgio mentioned this issue May 20, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working good first issue Good for newcomers P:linux
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@apyrgio @deeplow @sudwhiwdh