-
Notifications
You must be signed in to change notification settings - Fork 1k
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
[Feature request]: Access previously received messages on-device #1985
Comments
I forgot to include that deleting previously received messages is not a critical need, but would be nice to have. |
There are not very many messages stored on device, would this need to get / delete the message from the S&F device on the mesh? |
No, the intent is for a standalone messenger-type device (not paired with a phone) to store and display messages it has received without having to be dependent on a S&F device on the mesh. However, this received message database could also be used to store messages received from a S&F device on the mesh, in support of a broader S&F capability for all devices and not just a specialty use case solution for standalone devices.
This datastore might also be useful in other cases, such as feeding a web client where past messages are otherwise might not be retrievable. I don't know if that example is valid, or even a good suggestion but just proposing alternative uses for the on-device datastore. I also don't know how much nonvolatile storage space is available for any particular device, but retaining the last 20 received messages would be reasonable. Of course, more would be better and making that number configurable would be welcome if feasible.
Tony
…________________________________
From: Garth Vander Houwen ***@***.***>
Sent: Friday, November 25, 2022 12:48
To: meshtastic/firmware ***@***.***>
Cc: tropho23 ***@***.***>; Author ***@***.***>
Subject: Re: [meshtastic/firmware] [Feature request]: Access previously received messages on-device (Issue #1985)
There are not very many messages stored on device, would this need to get / delete the message from the S&F device on the mesh?
—
Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmeshtastic%2Ffirmware%2Fissues%2F1985%23issuecomment-1327746396&data=05%7C01%7C%7Cdcd99c620c7247dcca4b08dacf0d42a2%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638049953098198115%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PrYOo6KvcJ0Qjp1s3%2F07r%2FMAbSuQvJsQR%2B983nCA540%3D&reserved=0>, or unsubscribe<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAQ7GUPSZSSFM5M56DBLACADWKD3WXANCNFSM6AAAAAASKRIXYM&data=05%7C01%7C%7Cdcd99c620c7247dcca4b08dacf0d42a2%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638049953098198115%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mHZ9YToXcjhZyHXmcjNoclyvj9lH%2FE%2BGPFrMfCLkyRk%3D&reserved=0>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Any movement on this? |
I'm going to toss this onto the 3.0 project list simply because it can be part of the overall UI rework that's already planned. We have multiple device platforms now able to send/receive messages without an attached PC or phone running a client. It only makes sense that our firmware (and it's UI) should be able to display more than just the most recently received message (at least on devices with sufficient storage). |
How is this going? |
No progress, pull requests are welcome. |
This, would be really nice to have; come on 3.0... |
I realized today that long-pressing a rotary encoder doesn't do anything as it's not a 'real' user button, it just performs the user button select action. We'll have to change my proposed UI actions flow in my original issue description to figure out what to substitute for a secondary action (double press maybe?) |
The big question, IMO, is whether we can capture a long press, and treat it as the user button. And if we can, we probably should. |
Yes, long press would be quite valuable |
Up! |
unfortunately the cardKB firmware doesn't register long presses on keys other than Shift, Sym and Fn, changing that would require modifying the cardKB firmware. Another option could be Fn+Up (0x99) and Fn+Down (0xA4) and last suggestion would be to separate the CardKB settings from Canned Messages and create a Standalone Module which will allow for more standalone features and keep the code clean. Considering that canned messages would no longer be needed or as necessary with a full keyboard available. We've already implemented dissabling gps and notification with keystrokes which have nothing to do with canned messages, I can already see more features to come because of it. |
Request capability for users to access (and delete) previously received messages, stored on-device using the Store and Forward (S&F) module, and displayed on the device screen. This could be used for any device, not just standalone messengers with keyboard or rotary encoder but that is the intended use case. The 'one button' library supports button longpress and other features to support this.
I propose UI navigation solutions below to enable users to invoke a UI level to view and scroll through received messages; one for rotary encoder and one for CardKB users. Ideally a single solution would be implemented for simplicity, assuming there is a way to do so without conflicting with current button assignments. However, button assignments could be modified to support this.
This feature request is associated with feature request #1983 (Store and Forward module), which would presumably be required for this feature request to work.
Using a Rotary encoder:
4a. CW encoder rotation scrolls to the next oldest message received at 04:58
4b. CCW encoder rotation scrolls back to the newer received message
5a. CW/CCW encoder rotation highlights View or Delete, single press of encoder selects choice
5b. If user selects Delete, present user with confirmation "Delete this message?", single press of encoder confirms and the list of received messages is again displayed, minus the deleted message
5c. If user selects View, display selected message onscreen
5d. A second single press of encoder dismisses the message, going back to the list of received messages
6a. Longpressing encoder should also exit the received messages list and/or menus at any time
Using a CardKB keyboard (and future supported keyboards):
4a. Down arrow key scrolls to the next oldest message received at 04:58
4b. Up arrow key scrolls back to the newer received message
5a. Up/down arrow keys highlight View or Delete, enter key selects choice
5b. If user selects Delete, present user with confirmation "Delete this message?", enter key confirms and the list of received messages is again displayed, minus the deleted message
5c. If user selects View, display selected message onscreen
5d. Backspace key dismisses the message, going back to the list of received messages
6a. ESC key should also exit the received messages list and/or menus at any time
The text was updated successfully, but these errors were encountered: