Add command, window mode, and keybinding logic

hrdl-github commented 2 months ago

Most hardcoded shortcuts were replaced with a mode-dependent configurable shortcuts, which are mapped to abstract commands handled for easier handling.

The concept of window modes was introduced to allow conditioning bindings on e.g. whether the help mode is active or whether a message is selected. Most bindings were moved to WindowMode.Normal, which has the lowest priority and does not get considered when the help popup or the channel modal is shown. WindowMode.Anywhere takes precedence over all other modes. The remaining modes are usually inserted in between if they are active (Multiline, MessageSelected, Normal).

Keybindings are serialised from toml at startup. The default keybinding is active by default and can be overwritten via the configuration, e.g.

default_keybindings = true
[keybinding.anywhere]
ctrl-c = ""
ctrl-q = "quit"

Suggested tasks

[x] Show configured keybindings in the help menu
[x] List all commands in the help menu
[ ] Allow scrolling in the help menu: I'm not sure whether the widgets should be exposed in App or if there's a better way
[ ] Add default keybindings for scrolling the help menu
[ ] Enhance structure of help screen
[ ] Update commands and keybindings in README.md
[ ] Consume key events while in help mode to prevent simple key presses or Enter to be passed through

I'd appreciate your feedback on these changes.

hrdl-github commented 2 months ago

This would fix #307.

boxdot commented 1 month ago

Very nice! Thank you for your contribution! This is a big step forward. LGTM

hrdl-github commented 1 month ago

I've reworked some parts to use on strum's traits and macros for handling enums; I hope this makes sense. This is my first more sizable contribution to a rust project, so you might want to take a closer look. I've updated the most obvious tasks in the top comment.

boxdot commented 1 month ago

strum definitely makes sense. Parsing now looks simpler. I will merge the PR now. The follow-up tasks can be done in separate PRs.

hrdl-github commented 1 month ago

I'm unsure whether https://github.com/boxdot/gurk-rs/pull/315 caused operations like changing channels while downloading messages (especially shortly after startup) to be less responsive or whether this was an issue before. I'm going to test a non-async on_command function and report back.

hrdl-github commented 1 month ago

The main offender was https://github.com/boxdot/gurk-rs/blob/3caaad6f78e4b749745f486cdedc34499fadce1d/src/dev.rs#L90 that I use in my build. Without it the lag is significantly lower. I haven't investigated whether there are other blocking or slow components relevant to this. I'm using the json storage backend.

boxdot commented 1 month ago

The problem is that we do blocking IO there and therefore block the async executor.

hrdl-github commented 1 month ago

Just to be clear, are you referring to the storage backend or to dump_raw_message, which obviously is not intended to be used for non-development purposes?

boxdot commented 1 month ago

I am referring to dump_raw_message. Yes, this is just a very quick impl to inspect messages on disk.

A side note about the json backend: I plan to remove it completely.

boxdot / gurk-rs

Add command, window mode, and keybinding logic #315