Please open a Pull Request from your fork to the original main branch

[Mokhyy]

Hi @AsafMah ! Thank you for adding such amazing features to the project.

I really appreciate the work you've put into it. Could you please open a Pull Request from your fork to the original branch of leantype ?

This way, your changes can be merged into the mainline, allowing everyone to benefit from these new features and preventing code fragmentation.

[AsafMah]

I would be happy to contribute, however the maintainer doesn't want it - LeanBitLab#133

[Mokhyy]

@AsafMah

I think the maintainer probably wouldn’t mind accepting this PR; you just need to explain the benefits of the pull request to them.

In the version you built, glide typing has become noticeably smoother. On top of that, the blocklist and many of the other features you added are exactly the kinds of things users have been asking for in the issues.

I think it would be better to explain these points to the maintainer. Honestly, LeanType, which is a fork of HeliBoard, and HeliBoard itself, which is a fork of OpenBoard, both have old and somewhat messy codebases, and that makes the code fragile. Because of this, the maintainer is usually hesitant to add new features, since they may think it could make the code even more complicated.

But the features you added to LeanType are genuinely valuable, and it would be a shame if they remained only in your fork and were never merged into the main branch. You will probably also abandon the project sooner or later after completing these features, because continuing to develop a project forever is not easy and can become exhausting. For that reason, it would be better for these changes to be merged into the main project so that others can benefit from them and there is also a chance for their development to continue.

Also, I think instead of sending one large pull request, it would be better to submit the changes separately and in smaller pieces. For example, you could send one PR for adding the blocklist, another for touchpad scrolling, another for the clipboard, and so on for the rest of the features.

This would make reviewing the changes much easier and would also keep the PRs from becoming too crowded and messy. On the other hand, the maintainer would probably find it easier to decide on each part separately and, if needed, give more precise feedback.