Text to speech #34

No.

Building syntactic sugars around big techs' api does not add value for functional open source library such as quill. This is meant to be a text editor, imho, streching the feature set too thin is only going to hurt the adoption rate and usability. Library adopters usually has better opions/plans/competency to implement such a feature exactly on top of quill to their own specification if they are serious about introducing the feature to their own users.

Take image upload/edit/saveLocally popup function currently shipped with quill, it's borderline not usable, I don't think any developer would ship this function in that state in their product is they are any serious about thier project.

Take i18n, since its introduction there are simple bugs related to upper/lower case on naming conventions of resource files, and for a whole year no one bother's to fix the problem, they adopted one of the i18n library, but many adopters may want to use a different libary in their project, they did not realize they should make libraries such as quill i18n agnostic by delaying such decisions to the control of library adopters.

I have been using quill in the last two years or so developing my own apps on windows and mobile platforms, I discovered and worked around many issues. I am not sure if you feel the same, their team is difficult to get hold of, this seems to be a side project for them and communications often get lost for some reason.

Their team couldn't make up their mind on the end goal of quill. Erring on the side of being reckless, I take the liberty to share my opinions on this library and hopefully if we find some common ground, I can also contribute some time to make it better, even though I don't have time to take it into my own hand.

1 Be very clear with the scope and use case of quill.
The libary should be robust, easily composable (with stable api and good abstraction) and effficent to handle document of say less than 2000 words. this is roughly 4 A4 size pages worth of text. This should cover over 90% of the use cases, for the rest of the cases I highly recommend adopters split the full text into multiple chunks (either for storage or during rending) to

• take full advantage of flutter rendering mechanics to prevent yanks,
• make their full text analytics easier to implement and yeilding better more fine grained result
• take advantage of the fact that the underlying datasturcture, unlike word format or xml, is a sequential flow of decorations, which is so much easier to manipulate.

That being said, the maintiner should not make rendering/parsing algorithmic performance their first priority, performance issues on large text with over 40 pages can wait.

2 Enforce coding standard and raise code quality.

In many occasions I drilled down quill's source code extensively to solve my own problem, and obviously

• the project is ported from js,
• they seiously did not enforce any kind of coding standard.
• many implementations with type information missing.
• they do not use any lint to help with their coding
• Some junior devs worked on the project did not seem to know what they were doing.
• api not well designed with many bandaid all over the place to fix problems temporarily.
• private methods and messag passing carries relics from js and not making better use of dart's language features. Internal api design is a big meh and seriously need to be revamped.

these really need to be cleaned up, i mean, many bugs could be revealed/fixed automatically simply by turning on lint and let compiler and static analysis do their work properly.

3 less features rather than more features.

Implementing ui widget is so damn cheap and easy in flutter and swiftui, third party functional library such as quill should not be concerned with building these ui features at all, they won't share the same look and feel with the rest of the app, leave the possibility open,

for example the pick a photo/resize/crop UI library imported by and shipped with quill is just crap, why bother, adopting devs can choose to import or build one themselves in a few minutes, don't force every library adopter to import these libraries by default. the same goes with icon tips and i18n etc. Make the libary lean and thin, don't force adopters to transitively import libs they don't ever need.

4 format interoperability

take over the responsibility of maintaining interoperability/translation between quill data format <->markdown <->html<->pdf/word, this does not need to go into the core quill library, but should be maintained by the same group of people in a second project. Standardizing and simplifying such translations should be promoted and well maintained to attract adopters. currently you can see that the quill<->markdown translation lib on pub.dev is almost not maintained and many adopters don't realize how easy it is to translate quill format into markdown by implementing the missing features on their own with a few lines of code, this should be publicized somewhere with some examples. where it should also make it explicit that the expressive power of quill/markdown is a strict subset of xml, hence certain document structures in word/pdf is never going to be possible with quill, but foregoing such expresiveness gives you an immensely easier data structure to reason and work with.

5 tutorials rather than features/documentation

personally i think the code base of quill is quite easy to understand even for beginner devs once they turn on lint and fix all those compilers warnings about missing/mismatched types. A full tutorial on implementing a particular custom icon implementation is probably good enough to get them through all the difficult part about available hooks and controller lifecycles, once they are comfortable navigating around the code base to find what they want on their own, documentation is not that important to them anymore. this way you won't be forced to maintain documentation on all those evolving parts.

@kairan77 Thank you very much for your in-depth feedback. I'm very happy to see interest from a long term quill user. There are many spots where I'm still acquiring knowhow in Quill and many places where things can be improved. All your feedback will be highly valuable. I guess you are already on the discord server. If you plan to join the effort later I'll be available on audio calls. I see you wrote quite a few messages, I'll attempt to answer them all, this being the first one.

1. Building syntactic sugars around big techs' api does not add value for functional open source library such as quill. - Fair point. I don't think we should tie in too deep into any particular big tech. I was more interested to use the local APIs on the particular platform, for example Chrome has already some native text to speech which is generated locally. Obviously it's of rather low quality. So maybe it's not a great choice. But at the same time I think it will get better in time. So maybe this can be done only by using the platform APIs. Overall It's just a nice to have. So maybe we will skip it completely. Definitely it's not something worth the time and effort for now.
2. image upload/edit/saveLocally popup - At the moment my first goal is to make the images work on the web build as well. Current quill repo has ignored web and also failed to provide a clear explanation of why they are doing so. Would be interesting to discuss the popups in a standalone ticket.
3. i18n - I haven't dug in too deep in this topic. Not sure what Quill aims to provide in this regard. Afaik it does some translations for toolbar buttons tooltips + a few modals and that's kinda of it. Meaning I don't see how that interferes with what the users are doing in their local app. If you can clarify in a distinct ticket, it would be nice.
4. their team is difficult to get hold of - That's exactly why I decided to byte the bullet and refactor Quill for my own usage. I'm working on a project that has very specific requirements from Quill and I never received any support for my queries. Then the architecture was extremely opaque and difficult to trace. So I decided that I need to fork it and do my own thing. I wrote more about the reasons to fork here.
5. Erring on the side of being reckless - Can confirm, the text size feature was added with no quality checks at all. The maintainers approved and released. Their approach is to beta test in production. This doesn't work for my app at all. Code needs to be policed.
6. Be very clear with the scope and use case of quill. - Well, given that I forked the repo in interest of consolidating the rich text features that I provide in my own flutter app the development path will be heavily influenced. I do require large documents. possibly even beyond 50 pages. The rendering logic seems to be able to render such large docs, what does lag is the parsing logic. At some point in time this will become quite a priority for me. At the moment first target is to make it easy to understand and stable (docs, testing, debugging) + adding more features. Currently working on highlights and markers.
7. split the full text into multiple chunks - Dealing with the scroll will be quite difficult.
8. Enforce coding standard and raise code quality. - Yes, this was heavily neglected. Won't be happening in this repo. I have direct interest not to.
9. private methods and messag passing carries relics from js and not making better use of dart's language features. Internal api design is a big meh and seriously need to be revamped. - I've spent a large amount of time untangling this mess. I've split the repo in modules and started separating the state of the editor in a distinct layer. Many of the contrived code pattern though come from the Flutter rich text API itself and can't be improved beyond a certain extent. I've had to keep passing some class references around. Though I'm doing my best to explain why and how.
10. turning on lint and let compiler and static analysis - Afaik it is working. I'm always cleaning the static analysis issues. Yes indeed they had a lot of junk lying around in the past.
11. Less features rather than more features. - It's hard to say what is extra and what not. From my angle I'll be desperately needing certain features (highlights, markers, tables, styled blocks, etc). Implementing them outside of the editor leads to huge performance issues. On the long run I do plan to introduce support for plugins such that not everything is delivered in one bundle. This might be especially important for web where payloads needs to stay slim.
12. the pick a photo/resize/crop UI library imported by and shipped with quill is just crap, - I'll keep it in mind to review and asses what changes can be done. I'm also pro removing libs. One that is currently removed si the tuple lib. It was not helping at all, actually it made the code worse by obscuring the types and leaving room for interpretation.
13. interoperability/translation between quill data format <->markdown <->html<->pdf/word - That's at the moment not on my prios radar. There's a limited amount of time I can invest and I have to pick my battles. If my product manages to become profitable, maybe I'll have the resources to expand to these concerns. At the moment I'm trying to stay focused on stuff that can accelerate my own agenda. Sounds bad, but yeah, there's a reason why I forked. I need some features really badly and conversion is not a prio for 2022. Might be in 2023.
14. tutorials rather than features/documentation - I've been collecting materials to produce video tutorials on how Quill was migrated. I've also created several sample pages showcasing the various modes in which Visual Editor can be used. In time more examples will be added. My current approach is to slowly increment and improve the docs and tutorials in parallel with other dev tasks. My limited time does not allow for faster solutions.

I hope that answers some of your concerns/comments. Looking forward for more discussions. In summary I do plan the best for the repo since it's an essential piece of kit that I really need, however my resources will allocated on targets that might not always match the general expectations. Otherwise it wont make sense for me to maintain the repo. I hope my work will end up benefiting a lot more people. And yes, I'd be happy to coordinate the development effort with more developers if any volunteer.

Cheers!

3. there are multiple i18n solutions (implementation) using different libs from pub.dev, they are not compatible, what i am saying is if the adopter of quill has already adopted lib A for their i18n, but quill use lib B for i18n, then we leave adopters in an ugly situation where he has to import both A and B in his project. That duplication is not ideal.
   6.7. on long document and scrolling, I use quill to display and edit book content, some books are over 700,000 words in length, they are usually split into a dozen tabs based on chapters, but then each chapter is still very loooong. What I have done is on the storage side I save each chapter as a single json entry in DB, but on the rendering side, I split those entries into say for eg. 70 'paragraphs' just before displaying, then i use 70 quill editors in a listview builder to individually display those 70 paragraphs, scrolling is fine and fast even for extremely long document, i can also instantaneously jump to a particular text accurately, on double click, to the position of audio playing in the background, yes the audio and the text are correlated audio books. This works. I too started with displaying the whole thing in a single quillEditor, but it's janky and slow, the scroll is also choppy. Take advantage of the datasturcture of quill's delta. If you encounter scrolling problem with multiple editors in a list, I can help you fix the problem, it's probably just a simple configuration thing.

agreed on the rest of the points, good luck, give me a shout if you still have problem with scrolling or on implementation of highlight/marker which I have already implemented for a different use case.