Rethink menuinst for existing Desktop files or App bundles.
- Dominant language
- Python
- Stars
- 50
- Forks
- 49
- Avg merge
- 1d 11h
- Merged PRs (30d)
- 16
Description
### Checklist
- [x] I added a descriptive title
- [x] I searched open requests and couldn't find a duplicate
### What is the idea?
We've been trying to package some Electron / Tauri / Rust applications and on macOS and Linux they usually already create their own App Bundle / Desktop file.
I was thinking: instead of trying to push everything through the menuinst.json file, we could perhaps also enable menuinst to copy/symlink an existing App Bundle or Desktop file to the right place, and possibly adjust it slightly to enable the conda activation.
That would make menuinst super flexible, and existing bundles (build outputs) work more easily instead of creating a new file or trying to wrap a App Bundle.
### Why is this needed?
Make the experience nicer for packaging desktop apps.
### What should happen?
Discussion!
### Additional Context
_No response_
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reviewing how menuinst.json currently represents menu items and how existing macOS App Bundles and Linux Desktop files are handled. The issue needs an agreed design for copying or symlinking those existing artifacts and optionally adjusting them for conda activation; done means the behavior and scope are decided before implementation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- electron, python, rust, tauri
- Domain
- desktop, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100