Future of non C++ backend languages and Qt frontend
-
if you do not use C++ for your business logic, Qt seems to push toward Qt Quick with Qt bridges.
- qtdotnet is migrating to Qt bridges.
- C#, Kotlin/Java, Python, Rust, and Swift are on schedule for being released as part of the Qt Bridges project.
There seems to be a desire to connect to Qt Quick (via Qt Bridges) and not to Qt QWidgets. Why?
Will Python move toward Qt Quick instead of PySide?
What future plans does Qt group have with QtWidgets? (I presume C++ only)More specific for this case, we look to move the frontend to Qt with a backend written in C#. Especially because this would allow the application to run on linux and windows (among other) instead of windows only. The application is a classical desktop application, there is not desire to move to web or touch based devices. That would make QtDotNet interesting since it combines QtWidgets with C#, unfortunately QtDotNet is archived.
Is there any combination of C# and QtWidgets possible in the future?
-
if you do not use C++ for your business logic, Qt seems to push toward Qt Quick with Qt bridges.
- qtdotnet is migrating to Qt bridges.
- C#, Kotlin/Java, Python, Rust, and Swift are on schedule for being released as part of the Qt Bridges project.
There seems to be a desire to connect to Qt Quick (via Qt Bridges) and not to Qt QWidgets. Why?
Will Python move toward Qt Quick instead of PySide?
What future plans does Qt group have with QtWidgets? (I presume C++ only)More specific for this case, we look to move the frontend to Qt with a backend written in C#. Especially because this would allow the application to run on linux and windows (among other) instead of windows only. The application is a classical desktop application, there is not desire to move to web or touch based devices. That would make QtDotNet interesting since it combines QtWidgets with C#, unfortunately QtDotNet is archived.
Is there any combination of C# and QtWidgets possible in the future?
@Gijs-Groote said in Future of non C++ backend languages and Qt frontend:
What future plans does Qt group have with QtWidgets?
I guess that most developers in this forum feel like QWidgets is mostly (but not fully) abandoned project. QML is continuously developed further, but QWidgets is stagnating. This might be related that for desktop applications you can use the open source license (only few are paying for a commercial license). QML is important for embedded, automotive, and mobile. For most (or all?) of these areas you have to buy licenses. So, this is where the money is. If you are a larger company and have dedicated designers, I would claim that QML is the better option (many designers can easily edit the design in QML or even use standard design tools). Few designers will be able to edit C++ code (in the case of QWidgets) to change the design.
-
if you do not use C++ for your business logic, Qt seems to push toward Qt Quick with Qt bridges.
- qtdotnet is migrating to Qt bridges.
- C#, Kotlin/Java, Python, Rust, and Swift are on schedule for being released as part of the Qt Bridges project.
There seems to be a desire to connect to Qt Quick (via Qt Bridges) and not to Qt QWidgets. Why?
Will Python move toward Qt Quick instead of PySide?
What future plans does Qt group have with QtWidgets? (I presume C++ only)More specific for this case, we look to move the frontend to Qt with a backend written in C#. Especially because this would allow the application to run on linux and windows (among other) instead of windows only. The application is a classical desktop application, there is not desire to move to web or touch based devices. That would make QtDotNet interesting since it combines QtWidgets with C#, unfortunately QtDotNet is archived.
Is there any combination of C# and QtWidgets possible in the future?
@Gijs-Groote said in Future of non C++ backend languages and Qt frontend:
C#. Especially because this would allow the application to run on linux and windows
So Qt c++ does not run on Linux?
Qt Online Installer direct download: https://download.qt.io/official_releases/online_installers/
Visit the Qt Academy at https://academy.qt.io/catalog -
@Gijs-Groote said in Future of non C++ backend languages and Qt frontend:
C#. Especially because this would allow the application to run on linux and windows
So Qt c++ does not run on Linux?
@Christian-Ehrlicher
I don't think that's what OP means. They are committed to a C# back-end. They mean that, if that could interact with a QWidget and not just Qt Quick app in the case of Qt Bridges, they could use Qt widget app as their cross-platform UI. -
@Christian-Ehrlicher, as @JonB correctly pointed out, we are committed to a C# backend. For this desktop application it would be unwise to commit to a Qt Quick application if support for C# with QWidget may become available in the future.
-
The application is a classical desktop application, there is not desire to move to web or touch based devices.
Qt Quick can do desktop applications.
Will Python move toward Qt Quick instead of PySide?
You can use QML and Qt Quick with PySide already. But's there also a python Qt Bridge too.
There seems to be a desire to connect to Qt Quick (via Qt Bridges) and not to Qt QWidgets. Why?
Less surface area to port to other languages.
To work with QML you just need to be able to expose types and objects with properties, signal and slots and some specific classes like QAbstractItemModel. This enables a simpler and more focused approach. -
if you do not use C++ for your business logic, Qt seems to push toward Qt Quick with Qt bridges.
- qtdotnet is migrating to Qt bridges.
- C#, Kotlin/Java, Python, Rust, and Swift are on schedule for being released as part of the Qt Bridges project.
There seems to be a desire to connect to Qt Quick (via Qt Bridges) and not to Qt QWidgets. Why?
Will Python move toward Qt Quick instead of PySide?
What future plans does Qt group have with QtWidgets? (I presume C++ only)More specific for this case, we look to move the frontend to Qt with a backend written in C#. Especially because this would allow the application to run on linux and windows (among other) instead of windows only. The application is a classical desktop application, there is not desire to move to web or touch based devices. That would make QtDotNet interesting since it combines QtWidgets with C#, unfortunately QtDotNet is archived.
Is there any combination of C# and QtWidgets possible in the future?
@Gijs-Groote said in Future of non C++ backend languages and Qt frontend:
What future plans does Qt group have with QtWidgets?
I guess that most developers in this forum feel like QWidgets is mostly (but not fully) abandoned project. QML is continuously developed further, but QWidgets is stagnating. This might be related that for desktop applications you can use the open source license (only few are paying for a commercial license). QML is important for embedded, automotive, and mobile. For most (or all?) of these areas you have to buy licenses. So, this is where the money is. If you are a larger company and have dedicated designers, I would claim that QML is the better option (many designers can easily edit the design in QML or even use standard design tools). Few designers will be able to edit C++ code (in the case of QWidgets) to change the design.
-
G Gijs Groote has marked this topic as solved
