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

Canonical location in PREFIX for menu item artifacts #113

Open
jaimergp opened this issue Feb 2, 2023 · 2 comments
Open

Canonical location in PREFIX for menu item artifacts #113

jaimergp opened this issue Feb 2, 2023 · 2 comments
Labels
stale::recovered [bot] recovered after being marked as stale type::feature request for a new feature or capability type::poc indicates some proof of concept or MVP work

Comments

@jaimergp
Copy link
Contributor

jaimergp commented Feb 2, 2023

The CEP preview of menuinst creates shortcuts for Linux, macOS and Windows in three default locations:

  • Linux: ~/.local/share/applications
  • macOS: ~/Applications
  • Windows: whatever the default locations for Start Menu, Quick Launch and Desktop are.

For this we create full files with computable paths, so we can re-obtain these paths at uninstall time if needed. The problem is that these files might not be there by the time we want to uninstall them (Windows users might rename or move the shortcuts, and they'd still work; macOS users might put the .app directory somewhere else; I am not expecting Linux users to mess with their .desktop files but you never know).

Instead of doing this, @goanpeca and I were talking about creating the actual menu files in PREFIX itself (under var/menuinst or similar), and the symlink to this canonical location from the system parts. This needs to be tested (specially on Windows, with different letter units?), but it should work. It would also have the benefit of having an easy-to-find location for the generated shortcuts without having to re-run menuinst to find out.

@jaimergp jaimergp added type::feature request for a new feature or capability type::poc indicates some proof of concept or MVP work labels Feb 2, 2023
Copy link

github-actions bot commented Feb 3, 2024

Hi there, thank you for your contribution!

This issue has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further activity occurs.

If you would like this issue to remain open please:

  1. Verify that you can still reproduce the issue at hand
  2. Comment that the issue is still reproducible and include:
    - What OS and version you reproduced the issue on
    - What steps you followed to reproduce the issue

NOTE: If this issue was closed prematurely, please leave a comment.

Thanks!

@github-actions github-actions bot added the stale [bot] marked as stale due to inactivity label Feb 3, 2024
@jaimergp
Copy link
Contributor Author

not stale

@github-actions github-actions bot added stale::recovered [bot] recovered after being marked as stale and removed stale [bot] marked as stale due to inactivity labels Feb 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale::recovered [bot] recovered after being marked as stale type::feature request for a new feature or capability type::poc indicates some proof of concept or MVP work
Projects
Status: No status
Development

No branches or pull requests

1 participant