eh2406 / rust-reader Goto Github PK

Would be good to know the terms under which modifications can be released.

we may also need to update our dependences.

It would be nice to add an Icon to the system tray, and give it a menu to access the functions that are only available in a hotkey.

I believe the std binary search functions have been improved to the point where we no longer need this dependency. But some investigation will be required to be sure.

lazy_static has been replaced by once_cell which in turn has been brought into std. Is the std API stable to do what we need? If not should we switch to once_cell?

So we can have several texts in progress at the same time.

If you try to launch rust-reader when it's already running, the second instance crashes: thread 'main' panicked at 'called Option::unwrap()on aNone value', src\main.rs:134:52

This is actually kind of the desired outcome (one instance remains running), but this behavior seems mostly accidental, and the crash has tripped me up a few times during testing. The error appears to be related to setting hotkeys, which I assume fails if that hotkey is already bound to the other instance of rust-reader.

Is there a "right" way to check if an instance is already running? Presumably setting the hotkey could fail for other reasons. FWIW, NVDA, by comparison, appears to terminate the previous instance when you launch a new one.

So that we can switch voices in settings.

I'm wondering what the best approach would be to make rust-reader usable without a keyboard, like on a Surface tablet. I'm thinking some sort of small, always-on-top window with just a play/pause button. I'm concerned that the change in window focus when tapping the button would interfere with the text selection. I guess this calls for some experimenting with the Win32 API.

winres Looks to be no longer maintained and has some significant bugs. For example mxre/winres#40

It looks like there is a fork https://crates.io/crates/winresource, so we should either switch to that or look up what the current best solution is.

We depend on an unmaintained fork of the preferences crate. I know it's unmaintained because I'm the one who supposed be maintaining it. There has to be something comparable that has been popularized in the ecosystem since preferences was abandoned, figure out what it is and switch to it.

We currently only show estimate % remaining, it would be nice to have time left.

So currently you can filter words with a regexp, by opening the settings file and editing the json.
It would be nice to have a way to see how the regex will affect the text to be read. Maybe with stored examples/test of texts.

Add a UI for changing the settings.