rubymamis

As @ahartmetz said:

> QML is absolutely not JavaScript. It's a markup language to describe user interfaces, spiced with JS for certain interactions. All heavy lifting behind the scenes is done in C++ - the QML runtime as well as the application logic and data models.

How's QML useless? It's incredible language for UI. I described how I developed my Block Editor (like Notion) in Qt QML and C++: https://rubymamistvalove.com/block-editor

You can see on the website: https://www.get-notes.com/pricing

You can pay for the Pro version to use advanced blocks such as kanban, images,Drop cap. Also, the free version limits you to 10 notes.

BUT, I'm planning to change that very soon, I will make all the current Pro features free and the only thing that will cost money will be cloud storage with real-time sync when I'll release the new mobile app.

Thanks for that! Really helpful advice here.

Hi there!

> The most common performance issues in decently written applications are rendering of invisible items aka overdraw

That's indeed what I found as well! Especially, these hidden items consume a lot of unnecessary RAM. What tools do you know for Qt/QML that can help with this issue?

What about Mojo?

I already showed in my benchmarks that my block editor is faster than all block editors on the market - even more than those that uses native frameworks. And there are ten of thousand of lines of QML code (and round the same of C++ as well).

You can't claim something is slow without showing empiric data. I showed mine when I claimed programming Qt C++ and QML together is fast. If you claim otherwise, you need to support it with data.

What exactly - from an end user perspective - do you worry about? Performance? I already showed in my benchmarks that my block editor is faster than all block editors on the market - even more than those that uses native frameworks.

And as I wrote to another commenter: "if you avoid writing Javascript code in your QML components, than most of your executable will end up being compiled C++ code. If you do write Javascript code in your QML components, than it could also be compiled to C++ code using the QML script compiler[1[2]."

BTW, I agree that there's not enough good documentation about communicating and connecting C++ and QML code. I hope I could write some tutorials for that in the future as I struggled with that when first delving into this.

[1] https://doc.qt.io/qt-6/qtqml-qtquick-compiler-tech.html

[2] https://doc.qt.io/qt-6/qtqml-qml-script-compiler.html

> The challenge, though, is there isn't really a good comprehensive list of those things the would allow you to compare the framework you use to native. And you can't patch everything if you don't even know where the holes are

> Yes, of course they can, but to do in reality requires too much effort, so you end up with with the state mentioned in the first part of the quote. (that's the whole point of the framework - to handle that complexity for you, and if the whole huge QT can't do that even though "they can" why do you think a single dev can?)

Yep. This is why I'm now working on a framework built on top of Qt that takes care of all these small but important details that takes time to figure out that Qt isn't equipped with built-in. For example, smooth swipeable StackView on mobile, support for native text handling on mobile, smooth scrolling on ListViews (that's horrible now), etc etc.

> So you now have constant layout shifts when you simply move your caret around.

That's a feature in such apps (look at Bear, etc). I plan to have an option to disable that so the editor is entirely WYSIWYG.

What frameworks do you suggest? I've covered in the blog post apps written in Fultter, web (React), Swift, etc. It's a ton of work building something like that from scratch, so I don't really see myself doing that.

> Saying “they’re both c++” is seems kind of misleading and meaningless right?

Not really, if you avoid writing Javascript code in your QML components, than most of your executable will end up being compiled C++ code. If you do write Javascript code in your QML components, than it *could also* be compiled to C++ code using the QML script compiler[1[2].

> QML apps that heavily implement core logic in javascript would be slow as balls.

The entire point is to separate logic and view where logic is written in C++ and QML simply represents the view (which almost end up being built upon simple primitives that *are* C++ objects). So if you keep this separation you get amazing performance with great simplicity and velocity.

[1] https://doc.qt.io/qt-6/qtqml-qtquick-compiler-tech.html

[2] https://doc.qt.io/qt-6/qtqml-qml-script-compiler.html

QML isn't slower than Qt QWidgets, in the end of the day Qt Quick components are simply C++ objects, you can look at the source code[1].

[1] https://github.com/qt/qtdeclarative

(Author here)

I think the fact that Qt went with Javascript as the scripting language for QML wasn't a smart decision - especially resulting in poor type safety. That said, they have improved the situation by a lot with required properties, Q_ENUM where you can now share enums between C++ and QML etc etc.

I don't agree that QML is just for simple UIs, that's exactly what I tried to demystify - my block editor is a very complex project spanning around 20,000+ lines of code - and still managed to be the most performant block editor in all my tests.

Contrary to you, I love the separation between the logic being written in C++ and UI in QML I think it's absolutely a great combo - QML is such a great language to write UIs in and C++ is a performant compiled language that (I, personally) love writing logic in. Also, communicating between C++ and QML components is straightforward with Q_PROPERTYs and signal and slots.

(Author here)

Wow just noticed my blog post is on the front page! Will try to respond to all comments here soon.

I thought about it as well. Might do it at some point.

Did someone do a deep dive on why battery life is so awful on Linux? Or is it some Ashai's driver's inefficiencies that causing this?

You can always use something like Little Snitch to not allow it to dial home.

Please share more info and images, if you can.

This looks awesome, looking forward to using it! Qt keeps innovate (although their built-in UI components slack behind).

It's still native (in terms of performance and ability to customize the look and feel) and working pretty well, it's just that not enough effort was put into making the built-in components behave and look like those on the platforms it runs.

Creating Daino Qt - a collection of components that makes Qt apps feel and look native on both Desktops and mobiles (each with its own set of challenges).

Developing Qt apps with C++ and QML is a blast - the fast performance of C++ and ease of use of writing UI in QML. But there is so much left to be desired with the built-in Qt Quick components - mobile issues like non native text handling, non native swipe-able stack view and much more. I’m aiming to bridge that gap.

What benchmarks are good these days? I generally just try different models on Cursor, but most of the open weight models aren't available there (Deepseak v3.2, Kimi K2 has some problems with formatting, and many others are missing) so I'd be curious to see some benchmarks - especially for non-web stuff (C++, Rust, etc).

I wish QML was part of CopperSpice.

Yes! I'm developing my note-taking app[1] for macOS and now working on a mobile version.

[1] https://get-notes.com

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.

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

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

Qt Quick components are just C++ classes[1].

[1] https://github.com/qt/qtdeclarative

Indeed, I wrote my note-taking app using Qt with QML: https://get-notes.com

I would plug my note-taking app written in Qt C++ and QML: https://get-notes.com.

I gave it the task to recreate StackView.qml to be feel more native on iOS and it failed - like all other models...

Prompt:

Instead of the current StackView, I want you to implement a new StackView that will have a similar api with the differences that:

1. It automatically handles swiping to the previous page/item. If not mirrored, it should detect swiping from the left edge, if mirrored it should detect from the right edge. It's important that swiping will be responsive - that is, that the previous item will be seen under the current item when swiping - the same way it's being handled on iOS applications. You should also add to the api the option for the swipe to be detected not just from the edge, but from anywhere on the item, with the same behavior. If swiping is released from x% of current item not in view anymore than we should animate and move to the previous item. If it's a small percentage we should animate the current page to get back to its place as nothing happened. 2. The current page transitions are horrible and look nothing like native iOS transitions. Please make the transitions feel the same.