Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Developing a Beautiful and Performant Block Editor in Qt C++ and QML

rubymamistvalove.com

Post reply on HN
Print view View original

41–50 of 66 posts

Re: Developing a Beautiful and Performant Block Editor in Qt C++ and QML

#41

Post by noodletheworld »

rubymamis wrote: post #38
didgetmaster wrote: post #33

I developed a new database management system and I needed a GUI application to use as an admin tool for it. I decided to build it using Qt (Qt Widgets in c++) mainly because my whole data engine is also in c++. Since it just uses standard windows and dialog boxes; I haven't felt the need to keep up with the latest Qt version. I am still using Qt 5 (I think revision 13 or 15). I have been contemplating moving to Qt 6.…

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

Hum…

QtQuick uses a different runtime which is (afaik) faster and targets modern graphics backends (eg. Vulcan) in a way widgets does not.

It also uses an a javascript scripting engine.

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

It’s probably more accurate to say QML is actively being worked on and receiving performance enhancements and updates and widgets is not, and has not for some time.

So yes, it’s actually pretty unlikely that QML would be slower (depending on what you do with your scripts) but it’s probably not as clear cut as you are suggesting.

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

Re: Developing a Beautiful and Performant Block Editor in Qt C++ and QML

#42

Post by pwdisswordfishy »

self_awareness wrote: post #32

> There's a misconception that you can't statically link your app when using the open-source LGPL version of Qt. From my reading of the LGPL license this doesn't appear to be the case. The LGPL allows you to statically link your app as long as you provide the object files and allow users to relink your app with a different version of Qt. I've observed many people spreading this misinformation about only being able to…

Yes, of course.

Re: Developing a Beautiful and Performant Block Editor in Qt C++ and QML

#43

Post by self_awareness »

pwdisswordfishy wrote: post #42
self_awareness wrote: post #32

> There's a misconception that you can't statically link your app when using the open-source LGPL version of Qt. From my reading of the LGPL license this doesn't appear to be the case. The LGPL allows you to statically link your app as long as you provide the object files and allow users to relink your app with a different version of Qt. I've observed many people spreading this misinformation about only being able to…

Yes, of course.

By calling dlopen() in runtime? Or how exactly?

Re: Developing a Beautiful and Performant Block Editor in Qt C++ and QML

#44

Post by mentos »

rubymamis wrote: post #23

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

Curious if you could snap your finger and implement your app in a few other frameworks for comparison which ones you are curious to evaluate next.

Re: Developing a Beautiful and Performant Block Editor in Qt C++ and QML

#45

Post by rubymamis »

noodletheworld wrote: post #41
rubymamis wrote: post #38

Earlier quoted context omitted.

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

Hum… QtQuick uses a different runtime which is (afaik) faster and targets modern graphics backends (eg. Vulcan) in a way widgets does not. It also uses an a javascript scripting engine. Saying “they’re both c++” is seems kind of misleading and meaningless right? It’s probably more accurate to say QML is actively being worked on and receiving performance enhancements and updates and widgets is not, and has not for som…

> 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

Re: Developing a Beautiful and Performant Block Editor in Qt C++ and QML

#46

Post by rubymamis »

mentos wrote: post #44
rubymamis wrote: post #23

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

Curious if you could snap your finger and implement your app in a few other frameworks for comparison which ones you are curious to evaluate next.

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.

Re: Developing a Beautiful and Performant Block Editor in Qt C++ and QML

#47

Post by rubymamis »

eviks wrote: post #19

> and Microsoft tends to abandon each new UI framework every five years So use the old one? Your first link literally mentions two ancient frameworks that are not abandoned (win32 and MFC) But you're right > So, it's more useful to ask: what do we expect from good native apps? 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…

> 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.

Re: Developing a Beautiful and Performant Block Editor in Qt C++ and QML

#48

Post by eek2121 »

rubymamis wrote: post #25
samiv wrote: post #22

I've worked with Qt about 15 years writing several applications both for work and for fun and overall I think it's a really powerful platform. Not without it's idiosyncrasies and quirks of course. That being said I find that QML is complete trash. It's fine for simple UIs with minimal logic and prototypes but for anything beyond that you'll always need to implement the logic in C++ and this is where the pain enters t…

(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 v…

IIRC, There are also bindings for other languages, at least I know Ruby used to have one that I played with.

Re: Developing a Beautiful and Performant Block Editor in Qt C++ and QML

#49

Post by Liquid_Fire »

self_awareness wrote: post #43
pwdisswordfishy wrote: post #42

Earlier quoted context omitted.

Yes, of course.

By calling dlopen() in runtime? Or how exactly?

The answer is linked to by the section of the article you quoted:

> (1) If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.

And also answered directly in the section you quoted:

> as long as you provide the object files and allow users to relink your app with a different version of Qt

Re: Developing a Beautiful and Performant Block Editor in Qt C++ and QML

#50

Post by rubymamis »

noodletheworld wrote: post #10

I've worked with QtWidgets and I have mixed feelings about the extensive (1) documentation about integrating C++ with QML and QtQuick. Here's a quick history lesson (as I understand it): - QtWidgets the original C++ QT graphics library. - Around 2008 or something, they introduced QML and QtQuick. This was basically declarative UI + javascript for logic. - QtWidgets is considered 'done' and all new features and dev is…

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

Post reply on HN