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.

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

Fancy Menu: misbehavior if an favorite app is disinstalled. #2028

Open
stefonarch opened this issue Feb 20, 2024 · 9 comments
Open

Fancy Menu: misbehavior if an favorite app is disinstalled. #2028

stefonarch opened this issue Feb 20, 2024 · 9 comments

Comments

@stefonarch
Copy link
Member

stefonarch commented Feb 20, 2024

Removing an application which was previously added to the favorites menu triggers 2 errors:

  • nothing happens if clicked
  • Right click displays "Add to favorites" but in fact it will remove it

screen_area_mar_20:11:06_

Expected Behavior

An error should be displayed if launched

Current Behavior

It gets removed if panel is restarted.

See above

Steps to Reproduce (for bugs)
  1. Add an application to favorites
  2. Disinstall it
  3. Click the item, right click the item in the menu/favorites
System Information
  • LXQt Version: git
@stefonarch
Copy link
Member Author

Didn't test immediately panel restart. So it's not a big thing.

@tsujan
Copy link
Member

tsujan commented Feb 20, 2024

We have telepathy: today I was going to test exactly the same thing.

Why did you close it? If an app is removed, it's logical to expect that its corresponding item under Favorites should be removed the next time Fancy Menu is shown.

@tsujan tsujan reopened this Feb 20, 2024
@stefonarch
Copy link
Member Author

I stumpled by chance open that, in my debian testing VM I had 2 pcmanfm, the gtk one and ours, so I removed it and saw it.

@tsujan
Copy link
Member

tsujan commented Feb 20, 2024

That doesn't rule out telepathy ;)

@gfgit
Copy link
Member

gfgit commented Feb 22, 2024

We could detect .desktop file being deleted with a dir watcher.
And also use XdgDesktopFile::tryExec() for some rare case where executable is removed but desktop file is kept and remove items returning false (might have some side effects if keeping desktop file was intended behavior).
Is there some hook like xdg updating mime cache which will inform desktop files changed?

Also please tag me in things related to FancyMenu because I really like following it's baby steps. Sometimes I miss these discussions.

@stefonarch
Copy link
Member Author

Also please tag me in things related to FancyMenu because I really like following it's baby steps. Sometimes I miss these discussions.

You can "watch" lxqt-panel and other repos of interest, to miss nothing.

@tsujan
Copy link
Member

tsujan commented Feb 22, 2024

We could detect .desktop file being deleted with a dir watcher.

I haven't looked into it yet, but I don't think watching desktop entries is the solution, because they can be in ~/.local/share/applications and persist after uninstalling apps.

@tsujan
Copy link
Member

tsujan commented Feb 22, 2024

Perhaps the most resource-friendly approach is tell the user about the absence of their executables (e.g., by showing a message when he tries to activate them) and let him to remove them. Just a suggestion....

@gfgit
Copy link
Member

gfgit commented Feb 22, 2024

You can "watch" lxqt-panel and other repos of interest, to miss nothing.

Thanks did't think of that.

Perhaps the most resource-friendly approach is tell the user about the absence of their executables (e.g., by showing a message when he tries to activate them) and let him to remove them. Just a suggestion....

I like it. Also I don't expect this would happen frequently.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants