Give setFrames more info - #2
Closed
todd-herbert wants to merge 2 commits into
Closed
Conversation
For now, this only solves the problem if the canned message module is disabled. Need to check with the authors to see if we can be even more restrictive here with intercepting ACKs
Author
|
Might need to handle this slightly differently, seeing how the plan is to draw the waypoint frame directly in the waypoint module. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
(For consideration: possible way to handle meshtastic#4043)
I've just thrown this one together right now on my way to bed. Hopefully it exposes some more information which you can use in
setFramesto decide which frame to change to. It's not implemented insetFramesyet, so it'd need a bit of a rewrite there. The new enum valueTARGETFRAME_PRESERVEis used to indicate that we should try to return to the same frame, but the other enum values passed make specific requests about which frame to show.It might be convenient too to use that
TargetFrameenum type to store some info insidescreenFrames, instead of theoldNumFramesstuff. Not sure about that though!Just submitting this as a draft, because I'm not 100% sure about it, but if you do want to try work with it, and get good results, feel free to merge it anyway.
I don't think anyone will object to observing the AdminModule this way, but you never know; will have to ask that tomorrow too.