-
-
Notifications
You must be signed in to change notification settings - Fork 189
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
Favorite-able WAV files #97
Conversation
Namely just for the sake of favorite-ing the cart lock/unlock. Requires changes to WAV player ext fap, as to be PR'd from the Momentum-Apps repo.
that sounds like the best course of action, yes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but will wait to merge as i'm guessing by merging the PR into apps repo the commit ID will change for the submodule
Great! PR'd the apps repo; once that's merged will push another commit here if needed for handling the commit ID bookkeeping |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks!
about the favorite timeout, that should be mostly irrelevant. the idea for it is to quit favorite files after a configured amount of time, makes sense for things like subghz files and nfc and rfid, not so much for wav files |
What's new
Primarily just wanted this feature for the sake of favorite-ing the cart lock/unlock WAVs.
archive
to recognize.wav
files as openable bywav_player
; as such enables "favorite" menu itemwav_player
to allow "direct launching" from a file, rather than requiring a file browser dialog to select the file after starting the FAP.The latter is messy / very quickly done as proof-of-concept. Doesn't yet impl the "favorite timeout" feature (have yet to use this myself so not actually sure what it does). Aside from that, anything missing that needs implementing to finalize this as a feature?
Given the required changes across both this repo and the submoduled apps repo, what's the best form for PR here? Shall I open a separate PR on the apps repo and reference the two?
For the reviewer