[Feature request]: Access previously received messages on-device

[tropho23]

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 https://github.com/meshtastic/firmware/issues/1983 (Store and Forward module), which would presumably be required for this feature request to work.

Using a Rotary encoder:

1. User longpresses encoder to access 'Received Messages' menu
2. Screen displays 'Received Messages' on top row of screen
3. Rows below top row display received messages in descending order (newest first)
4. Newest received message received at 05:00 is highlighted by default (inverse text) 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
5. Single press of encoder presents two choices to user: View and Delete (view highlighted by default) 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
6. Longpress encoder rotation dismisses the received messages list, returns to main screen 6a. Longpressing encoder should also exit the received messages list and/or menus at any time

Using a CardKB keyboard (and future supported keyboards):

1. User presses a custom key combination (e.g. fn key, then M key for example)
2. Screen displays 'Received Messages' on top row of screen
3. Rows below top row display received messages in descending order (newest first)
4. Newest received message received at 05:00 is highlighted by default (inverse text) 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
5. Pressing the enter key presents two choices to user: View and Delete (view highlighted by default) 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
6. ESC key dismisses the received messages list, returns to main screen 6a. ESC key should also exit the received messages list and/or menus at any time

[tropho23]

I forgot to include that deleting previously received messages is not a critical need, but would be nice to have.

[garthvh]

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?

[tropho23]

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 GitHubhttps://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 unsubscribehttps://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: @.***>

[Nikguy321]

Any movement on this?

[RicInNewMexico]

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).

[Nikguy321]

How is this going?

[garthvh]

No progress, pull requests are welcome.

[0100010]

This, would be really nice to have; come on 3.0...

[tropho23]

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?)

[jp-bennett]

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.

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.

[tropho23]

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.

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

[ea3iav]

Up! There are now at least three standalone devices populating the market. All that screens to just display the last message 😞

[HarukiToreda]

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.

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.

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.

[thebentern]

Closed by #3784 and #3259. Anything remaining can be opened in a Discussion or a subsequent Issue.