> I would rather have an app that is slightly slower than one that can crash unexpectedly. Even if they are quick to fix bugs, new bugs may be introduced in new releases. Your intent was to promote QT in your blog post, but unfortunately it has only affirmed to me that it's not something production-ready (QML on desktop).
Haha, that's interesting. But to be honest, it's really not that bad as it seems. Again, crash reports tend to be highly prioritized and most of the time you can find your way around them until they get fixed. It's indeed a frustrating experience when non-crash related bugs aren't being prioritized, but then again, like I explain in the blog, I could use a different library, probably an open source solution like I described using QBasicHtmlExporter[1] since QTextDocument toHtml uses weird inline HTML (and has some other bugs).
The thing is, with experience I kinda start to have my own boilerplate of battle-tested components/tools/libraries. I made the following client for Ollama[2][3] while not working on it full-time (still WIP) in around a month. It already is better than many web apps I tried who kept hanging while the model was generating a response. Also, try to copy text from a code block in web apps while a model is still generating a response -> it's almost always impossible since most web apps keep re-rendering everything on each completion, while I (like the native macOS chatGPT app) do incremental parsing which is much more efficient. The binary is 28MB (and can be even smaller), the app is fast and can handle very large amount of data. So I can build QML apps really, really fast these days due to the experience I gained and still gaining. I'm also wondering if I should open source my components as AGPL and then have some commercial licensing for it... Not to mention, I rarely use my own heap allocations myself - I try to put as much as I can either on the stack or in QML - so Qt handles all the heap allocation itself. While I'm relying on Qt to do an appropriate job, it seems to be very, very stable for now.
Haha, that's interesting. But to be honest, it's really not that bad as it seems. Again, crash reports tend to be highly prioritized and most of the time you can find your way around them until they get fixed. It's indeed a frustrating experience when non-crash related bugs aren't being prioritized, but then again, like I explain in the blog, I could use a different library, probably an open source solution like I described using QBasicHtmlExporter[1] since QTextDocument toHtml uses weird inline HTML (and has some other bugs).
The thing is, with experience I kinda start to have my own boilerplate of battle-tested components/tools/libraries. I made the following client for Ollama[2][3] while not working on it full-time (still WIP) in around a month. It already is better than many web apps I tried who kept hanging while the model was generating a response. Also, try to copy text from a code block in web apps while a model is still generating a response -> it's almost always impossible since most web apps keep re-rendering everything on each completion, while I (like the native macOS chatGPT app) do incremental parsing which is much more efficient. The binary is 28MB (and can be even smaller), the app is fast and can handle very large amount of data. So I can build QML apps really, really fast these days due to the experience I gained and still gaining. I'm also wondering if I should open source my components as AGPL and then have some commercial licensing for it... Not to mention, I rarely use my own heap allocations myself - I try to put as much as I can either on the stack or in QML - so Qt handles all the heap allocation itself. While I'm relying on Qt to do an appropriate job, it seems to be very, very stable for now.
[1] https://github.com/Open-App-Library/QBasicHtmlExporter
[2] https://rubymamistvalove.com/client.mp4
[3] https://www.get-vox.com