Earlier quoted context omitted.
Yes, of course.
By calling dlopen() in runtime? Or how exactly?
By linking the provided proprietary object files with Qt compiled from source.
Developing a Beautiful and Performant Block Editor in Qt C++ and QML
51–60 of 66 posts
Re: Developing a Beautiful and Performant Block Editor in Qt C++ and QML
#52Earlier quoted context omitted.
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…
> than it could also be compiled to C++
People who are going to use it should read the documentation.
“It depends” and “it’s still slow” are the fairest comments I can make about this.
Re: Developing a Beautiful and Performant Block Editor in Qt C++ and QML
#53I also think Qt/QML is a very underrated technology. I have been developing a handwritten notes for Linux/Windows using Qt Quick for quite some time [0]. The experience has been a mixed bag though. I've encountered tons of bugs (many of them still unfixed) that I had to find very ugly workarounds for. Also, while a declarative style UI language can have a lot of benefits, it does also have a lot of limitations. For e…
Qt Widgets is fantastic, but now dated since it has not been updated for the modern world. Plus it is C++, which a lot of devs dislike.
QML feels like a refresh with great ideas, bringing declarative UI and reactive programming. Where it falls short for me is it does not have feature parity with Qt Widgets, so you end up having to roll up your own components, wasting a ton of time. Dealing with layouts in QML is also an exercise in frustration.
Re: Developing a Beautiful and Performant Block Editor in Qt C++ and QML
#54I've always lamented that QML and QtWidgets are separate rather than integrated. It would be awesome if there was a declarative way to specify much of the same information that you have to specify programmatically with QtWidgets (e.g., the cumbersome process of defining nested sizers), and then you could write code to handle the actual "business logic". But instead we have two totally separate UI frameworks where you…
It exists since 2018 aha https://www.kdab.com/declarative-widgets/
That seems to be a third-party library that claims to add Qt Widgets support to QML, but it's hard to see from those examples how exactly it works. It still seems to be using a QML-style layout framework. What I'm saying is I would want to have an app that is entirely Qt Widgets, with the same behavior as if I had written it in code, but using a declarative language to specify as much of that information as possible. (Also I'd want to be able use it from Python with PyQt/PySide, not just C++. :-)
Re: Developing a Beautiful and Performant Block Editor in Qt C++ and QML
#55Earlier quoted context omitted.
> 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…
> than it could also be compiled to C++ People who are going to use it should read the documentation. “It depends” and “it’s still slow” are the fairest comments I can make about this.
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.
Re: Developing a Beautiful and Performant Block Editor in Qt C++ and QML
#56Earlier quoted context omitted.
> 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…
> than it could also be compiled to C++ People who are going to use it should read the documentation. “It depends” and “it’s still slow” are the fairest comments I can make about this.
If you ever run into trouble with execution of JS slowing down your Qt/QML application, you are using way too much JS. The most common performance issues in decently written applications are rendering of invisible items aka overdraw (especially on very weak embedded SoC GPUs) and slow startup time. There is tooling to find these and ways to fix or improve them.
Re: Developing a Beautiful and Performant Block Editor in Qt C++ and QML
#57I also think Qt/QML is a very underrated technology. I have been developing a handwritten notes for Linux/Windows using Qt Quick for quite some time [0]. The experience has been a mixed bag though. I've encountered tons of bugs (many of them still unfixed) that I had to find very ugly workarounds for. Also, while a declarative style UI language can have a lot of benefits, it does also have a lot of limitations. For e…
Qt Widgets is fantastic, but now dated since it has not been updated for the modern world. Plus it is C++, which a lot of devs dislike. QML feels like a refresh with great ideas, bringing declarative UI and reactive programming. Where it falls short for me is it does not have feature parity with Qt Widgets, so you end up having to roll up your own components, wasting a ton of time. Dealing with layouts in QML is also…
Not having an extra language to deal with and so many features being just a flag away is why I decided to go with QtWidgets for the GUI of a project I am working on at work. And it is so nice to use despite being very old. For the graphically intensive parts I am just using Vulkan. I understand this might not be enough for all types of GUIs though and just wish QtWidgets had some sort of GPU acceleration.
Re: Developing a Beautiful and Performant Block Editor in Qt C++ and QML
#58Earlier quoted context omitted.
Qt Widgets is fantastic, but now dated since it has not been updated for the modern world. Plus it is C++, which a lot of devs dislike. QML feels like a refresh with great ideas, bringing declarative UI and reactive programming. Where it falls short for me is it does not have feature parity with Qt Widgets, so you end up having to roll up your own components, wasting a ton of time. Dealing with layouts in QML is also…
Not having an extra language to deal with and so many features being just a flag away is why I decided to go with QtWidgets for the GUI of a project I am working on at work. And it is so nice to use despite being very old. For the graphically intensive parts I am just using Vulkan. I understand this might not be enough for all types of GUIs though and just wish QtWidgets had some sort of GPU acceleration.
[deleted]
Re: Developing a Beautiful and Performant Block Editor in Qt C++ and QML
#59Earlier quoted context omitted.
> than it could also be compiled to C++ People who are going to use it should read the documentation. “It depends” and “it’s still slow” are the fairest comments I can make about this.
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 supp…
[dead]
Re: Developing a Beautiful and Performant Block Editor in Qt C++ and QML
#60Earlier quoted context omitted.
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.
I'd be really interested in your thoughts on Godot with C++ support. Like, are there immediate showstoppers that pop into your mind?