Skip to content
This repository has been archived by the owner on Aug 1, 2024. It is now read-only.

Suggested Features List #5

Open
hmpthcs opened this issue Oct 30, 2023 · 0 comments
Open

Suggested Features List #5

hmpthcs opened this issue Oct 30, 2023 · 0 comments

Comments

@hmpthcs
Copy link

hmpthcs commented Oct 30, 2023

First off, great work on this so far. I have tested both the python and C++/QML versions and very much look forward to seeing this project progress. Stylus-based input methods under linux have been lagging behind for...decades.

I noticed that the latest version is missing many features that are already present in the older python version. If there are specific tasks needing to be addressed to bring up the new version, I am happy to help in whatever way I can.

Below are a list of suggestions I think would really enhance usability. I have mostly been testing the python version as the C++ version doesn't seem to go beyond setting up the UI. I should also note that I am using a wacom device with an e-ink screen, so that heavily biases my experience.

Thank you for your work on this so far, it's a fantastic start to filling what has been a very stubborn gap in linux software.

High priority:

  • Speed/latency/lag: in the python version, stylus input became laggy before grinding to a halt as the recognition process began. Some kind of delay between last touch point and starting up tesseract may help. Also, consider using "PROXIMITY_OUT" events instead of last touch point here to be more in sync with the user. In addition, stylus input is a bit sluggish from the very start--some work in the last year or two on xournal++ has shown how latencies can be brought quite far down, and I am confident the same can be done in this QT-based framework.
  • Wayland: python version uses pynput, which does not work on wayland. I tried to have the script use "wtype" as a subprocess, but this caused new problems--maintaining keyboard focus didn't work so well on sway, making the app unusable. Making use of wlr_input_method would be really nice here as it would open doors for use on many other wlroots compositors.
  • Configuration: should be possible at least through command line flags; better yet via a dedicated config file. The grey color scheme doesn't work so well on e-ink, and things like font family + size would be nice to change without recompiling.

Would be nice:

  • Input method editor integration as a first-class feature
  • Customizable recognition engines and methods --> e.g.: use stroke vector data instead of bitmaps; user configurable models; active feedback / refinement of models through use
  • Selection of phrases, words and individual characters with dropdown menu options for alternates.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant