feat: delete book from SD card via long-press BACK

[pablohc]

Improvements

Add ability to delete a book from the SD card by long-pressing BACK (~20 frames / ~1s) on a MainMenu entry.

ListMenuScreen

• Virtual on_long_back(index) method for subclasses.
• Long-press threshold configuration with hold tracking.
• Navigation blocked while button held to prevent race conditions.
• Normal BACK tap deferred until release — if released before threshold, on_back() fires normally.

DeleteConfirmScreen

• Shows the exact filename with extension (word-wrapped across multiple lines, breaking at '.', '-', '_' and spaces).
• Two options: Delete / Cancel (Cancel pre-selected).
• Delete removes EPUB file, cache directory, and BookIndex entry.

BookIndex

• Added remove_entry(index) for in-memory entry removal.

Screenshot

To avoid confusion when deleting a book (for example, books in the same series that start with the same text), the filename is displayed before confirming the deletion.

[CidVonHighwind]

How about putting the delete action onto a side button? Then we don't need to wait for a long press. With the long press change the ui now needs to wait for button release instead of directly moving to the settings screen. I feel like navigating up/down with the side buttons doesnt make much sense anyways.

[pablohc]

How about putting the delete action onto a side button? Then we don't need to wait for a long press. With the long press change the ui now needs to wait for button release instead of directly moving to the settings screen. I feel like navigating up/down with the side buttons doesnt make much sense anyways.

I have some concerns about using a single click on the side buttons. For those who use them to switch pages in Reader mode, this could lead to mistakes when navigating the menus and accidentally opening the delete confirmation menu.

Regarding the current implementation, based on typical user behavior, a standard tap usually falls well below the 1-second range, so the Settings screen remains very accessible without the long-press delay.
The "wait" feeling only happens if the user intentionally holds long enough to delete; otherwise, navigation is instant.

Could you clarify if your concern is specifically about the dual functionality of the BACK button and changing to SELECT solve the issue? I feel that the hold-detection mechanism prevents any accidental presses that could result in a destructive action like that.

[Gornun]

While walking around with it in my pocket, buttons get pressed. I often find it unlocked and on a different screen than where I left it (regardless of firmware).
Unless I'm unique, I think destructive actions should be difficult to achieve.

[CidVonHighwind]

The "wait" feeling only happens if the user intentionally holds long enough to delete; otherwise, navigation is instant.

My problem is that it feels worse. Currently the navigation to the settings screen is instant (when button is down). With the change this will be slower. It's not that big of a deal but I would still like to find a better solution for this.