| ▲ | wonklebonkle a day ago |
| Iced is a wonderful dead-simple framework. I hope it forever maintains the simplicity which combines nicely with Rust’s features. One thing I love about Iced and miss in Qt is writing the software in a single language. Qt has chosen to introduce multiple languages into their framework which makes the entire codebase a huge learning curve. In Qt you write your display layer in QML then your UI logic in Javascript and any backend advanced logic in C++. It is frankly exhausting. In Iced you write in Rust and use Cargo packages. This gives the developer ultimate composability and clarity of their application as well as powerful tools from an established ecosystem. If Qt wanted to provide a powerful Qml tool, they have to write it and build all of the IDE integration. For the record Qt used to be moving in a pure C++ direction but that changed when Qml came onto the scene. |
|
| ▲ | rubymamis a day ago | parent | next [-] |
| I actually love that separation. QML is a great language for writing beautiful, responsive, modern UI with animations easily. C++ is great for performance and logic. I don't like Javascript but I don't need to write a whole lot of it. I wrote my note-taking app's block editor in QML and C++ if some people are curious[1]. [1] https://rubymamistvalove.com/block-editor |
| |
| ▲ | 0manrho 5 hours ago | parent | next [-] | | Yeah, I appreciate the separation as well actually, even though I'm not a fan of the langauges involved (no issue with QML, dislike JS and C++). I've made a few things with Qt and despite my feelings on the languages, found it to be pretty useful and capable, and the learning curve wasn't that bad imo. I can't recall using much JS to be honest, but it's been a hot minute since I worked with that. That said there's simplicity to Iced being pure rust managed through cargo that I enjoy. Though it should be said that my "learning curve" for Iced was much lower than it might be for others as I discovered it well after I'd adopted Elm (which inspired Iced) and - independently - Rust, so Iced was pretty easy for me to grok. I don't think there's a right/wrong way there to be honest, both approaches have their pro's/con's, and my main issues with Iced vs Qt is largely a matter of maturity/prevalence than any specifics with the implementations/workflow themselves. | |
| ▲ | mroche a day ago | parent | prev | next [-] | | I gave Notes/Plume a try a year or so ago, it was an interesting experience. I ended up falling back to Joplin as I could use it on macOS, iOS, and Fedora with synchronization via Dropbox. I've always been curious about productizing apps like these, from a financial/business perspective have you found Daino worthwhile or enough of a success (by your standards) to continue developing it as a proprietary application? | | |
| ▲ | rubymamis a day ago | parent [-] | | Hi! That put a smile on my face (: I'm working now on a mobile version with real-time sync, so maybe give it another try when it comes out. Not really, not yet. Once my FOSS app was popular I used to earn a livable amount of money from ads on the website. But after a SEO crash that all went down the drain and the money I'm getting now from subscriptions to Daino Notes is nice but not livable. I've been working the last year (at a really awesome place) doing React programming (my first salary job, actually) and at nights and weekends working on Daino. I actually got many requests to license Daino Notes' block editor. So I've figured there's a business there. I'm working on something I'm calling Daino Qt which is a collection of different components to accelerate Qt apps development (so I'm also its client). It will include my block editor, components for mobile - current Qt components on mobile are extremly shitty - so I'm planning on changing that with things like native-feeling swipeable stack view, native-feeling text editing, etc. And maybe Qt C++ client SDK for InstantDB (and more stuff). Hope I can sell this as well while also consuming these components for Daino Notes and other apps I will develop. |
| |
| ▲ | wonklebonkle a day ago | parent | prev [-] | | Did you ever write a pure C++ Qt application with QtWidgets? | | |
| ▲ | rubymamis a day ago | parent [-] | | Yes, my FOSS note-taking app[1] used to be pure Qt Widgets. Recently, I've added the Kanban feature that uses QML (this and the editor settings should be the only parts in QML, if I remember correctly). [1] https://github.com/nuttyartist/notes |
|
|
|
| ▲ | ktpsns a day ago | parent | prev | next [-] |
| Haven't used Qt for a few years, but back then QML, QtQuick, etc have been optional features. You absolutely could write all your Qt logic in C++ only, in a somewhat similar way like the code shown in the iced READMEs. It is the same in any other classic GUI toolkit such as GTK+. Biggest drawback in qt/c++ used to be the MOC. I guess they still have not gone rid of it, haven't they? |
|
| ▲ | dotancohen a day ago | parent | prev [-] |
| I write all my Qt in Python. I've never used the C++ bindings. But in Python you don't need to deal with QML or JavaScript. |
| |
| ▲ | amelius a day ago | parent | next [-] | | I did some Qt programming in Python (PySide6), but ran into segfaults, which should of course not happen no matter what you do in a scripting language (except when using modules like ctypes). Many of these cases were related to object lifetime handling which is difficult to do correctly in Qt, and many people have written about it. In Python (a garbage-collected language) one should not have to worry about this. | | | |
| ▲ | wonklebonkle a day ago | parent | prev [-] | | Are you writing QtWidgets or QtQuick in Python? My understanding is that QML is mandatory for QtQuick apps. | | |
|
