I've been getting more and more interested with qt development. As a linux user, I'm exhausted from the bloat and cycle stealing electron apps ( with VSCode being a notable exception to this rule).
But more recently, the idea of writing one app in Qt, running it everywhere between Android, a Librem 5, and desktop platfoms is really exciting.
That was the main idea behind Pyre-Qt, but dynamic media resizing is not well supported in Qt unless you pull in a web view (at which point you've recreated Electron).
One fork of Pyre does this using a web view, and it fixes the media scaling bug, but what is the advantage over Signal Desktop at that point (besides being a tray icon & having native integration)?
When I was looking for a new editor, out and out excluded anything that didn't use either Qt or WxWidgets. What I saw was both frameworks allow you to at least support Linux, BSD, OSX, and Windows without too much hassle. It's been a while but my impression was Qt applications look like Qt applications and WxWidgets look more like native-ish applications. (But could probably am wrong).
I don't know how Qt & Android fare these days... I know it was quite a hassle to create background services when I first tried to get into it and there was no definitive answer as I think it was still on the roadmap to add it (perhaps?).
Qt is amazing and so is QML. I still found QML JavaScript engine utilizing a lot of memory back then as well and I don't know if it has been fine-tuned these days.
Even with native Java/Kotlin on Android it's pretty hard to reliably run background service, if not to say impossible (most manufacturers make it impossible, and even on Google devices it's impossible on Marshmallow).
I had to create a Qt JNI app... That was entirely run as a background service. It was quite the wizardry, and did require a little bit of Cyanogen kernel hacking from a coworker.
If you want a background service you currently have to create the code for it in Java, and call that code with the JNI. You can register callbacks for communicating the other direction (towards native code). A pain, but possible.
It's not a comparison I can do. I haven't used ionic extensively enough to put out a well-thought out comparison that can expose the layers of complexities and the pros and cons of how we can benefit from each technology.
I have yet to use electron tho... I haven't done a personal project in a long time to play with it.
This is an app I've been using written in Qt/QML that works on desktop and mobile, it doesn't seem like there's a whole lot of differences to make it work on mobile: https://github.com/alamminsalo/orion
Not really a real-world app, but a simple QtQuick with Qt3d app worked pretty well. When it comes to app sizes, a vanilla Qt app produces an apk file of ~15MB, which is reasonable.
I had troubles accessing external storage (the SD-card), and ended up writing quite some ifdefs to fix that. Probably the kdab folks have proper solutions to most common issues, but at the end of the day the idioms between desktop apps and mobile apps are quite different, and you will end up wasting time to fix those issues if you really believe in having a single code base for cross-platform apps.
I had a Qt app for MeeGo and Symbian, and later ported and released it to Android too. I didn't like the use experience, so I rewrote in native Android some five years ago or so. Code was fine, but the UI was a lot of work and still felt a bit out of place.
I have in the past developed a fairly large (proprietary) Qt application that used the same codebase on Linux, Windows, and Android. I would say Windows and Android are tied for compile hell.
This update looks really neat, and may solve some problems for some people. But personally my biggest gripe with Qt is qmake.
When you are doing Android, lots of resources assume Gradle, and lots of Qt stuff assumes qmake. Neither is ideal if you're dealing with other libraries like gstreamer, or even worse: proprietary libraries compiled using an old NDK.
So I ended up writing my whole build system in cmake, which made builds on Windows and Linux a lot saner, but made Android a living hell. I'd love to see better support in Qt for actual sane build systems you can use with real world third-party libraries, because qmake is not it in my experience.
I think the pain is unfairly attributed to Qt. A lot of the pain actually comes from the poor tooling in the C++ world.
Conan is supposed to come to the rescue, but after attempting to use it, it feels like it's still not as easy to use as any other package manager (npm, pypi, gems, etc). I love C++ and Qt, but It's extremely difficult to convince people to start any new projects in C++.
Common C/C++ questions and answers in stack overflow: how do I do x in C++ (e.g. trim whitespace), the usual responses:
1. It's trivial to implement, do it yourself.
2. Why would you want to do that.
Compare that to pulling up a library to do that, or it's already baked into the standard library (e.g. Java).
I would not want to develop a new application in C++, both Google and Mozilla decided it was bad enough they had to write better languages (Go & Rust), and the speed at which I can write things in Python, Lua or another lanugage is much faster than C++.
That being said, my SO would love you! He is always trying to get me to write things in C :D
std::string is laughably underpowered in comparison - it's basically a vector of bytes, missing a huge amount of convenience methods and all Unicode support.
building Qt apps with CMake is already possible and supported. Building Qt itself with CMake is an active project, and the long-term plan is indeed to drop qmake completely.
The XCode cross-compile is incredibly smooth, and the runtime is complete ass. Qt really messed up high-DPI support and it has no better example of this than iOS.
I tried to cross compile my Qt project from Linux to Windows.
It started, but then it crashed. So I gave up on that, and let someone compile it directly on Windows. Then there are no issues.
I did not try Android there.
Then I have another app that runs on Linux, Windows and Android using FreePascal/Lazarus rather than Qt.
FreePascal is really great for building. You only need to set the search path, and then it finds all the files it needs (just sometimes it crashes when serializing the dependency graph, then you need to delete all object files and restart).
Cross compiling from Linux to Windows works perfectly. FreePascal has an internal linker, so you do not need any other software for Windows. You do not need to deal with proprietary libraries, because there basically are no FreePascal libraries, especially no proprietary.
Linux-Linux cross compilation is more complicated. I just got a new computer and my 32-bit build failed silently because I did not have 32-bit gtk dev files and crtbegin from gcc installed. Yesterday I tried to install them with apt, but the installation failed, because they were conflicting with the 64-bit gtk dev gir files. Then I set force override in apt, and the installation worked, and then FreePascal cross compiled correctly. However, today I noticed, apt had uninstalled Python, Mercurial, Tortoise-Hg and most TeXlive packages. There must be something very wrong with Ubuntu's multiarch support.
There are three ways to run a Lazarus GUI on Android. First LAMW which has created a lot of FreePascal JNI wrappers around Android Views (and is far too complex for my liking); secondly Lazarus Customdrawn which draws all controls directly in FreePascal (and looks like it was designed to be Windows 98 compatible and crashed) and thirdly Qt, because Lazarus supports Qt as GUI backend (which probably works on Desktop, but I do not know anyone using it on Android). Hence, I compile my app as .so, export the data through JNI, and wrote a completely new GUI in Android Studio without using anything of Lazarus. Gradle does not need to know anything about FreePascal, it just copies the .so to the apk. But theoretically Lazarus is all you need. (Then I tried to submit my app to F-Droid, but they cannot include FreePascal/Lazarus apps, too complex build process)
Building Qt apps on windows is trivial if you use Visual Studio as a first class project with a few Qt specific msbuild targets, there are a few floating around. Then moc'in a header is as simple as using <MOC> element in vsxproj instead of <Include>, similar for UI and RCC, etc.
Does mean you have a platform specific build system though.
What are the technical reasons to prefer Qt over JavaFX[1]? Even Bitwig Studio, which is a C++ audio application, went with JavaFX for its cross-platform UI. It can also be written in React-like declarative style[2], which is much easier to maintain.
The things that are missing in standard C++: Unicode, SQL, filesystem (kind of fixed in C++20 or so), serialization, network protocols, JSON, XML, an event loop(!), signals and slots, a thread pool, compiled-in resources, runtime plugin support, etc
OpenJDK is now the 'official' JDK and reference implementation with Oracle making proprietary forks for their own customers, supported on their own timelines.
Java is actually doing some really interesting things since Java 9, with modular runtimes, pluggable garbage collectors, new compilers (Graal) and the Clojure crowd are being swept along with it simply by stint of being on the JVM.
For people new to Qt: It's a cross-platform GUI framework. It's written in C++ but can also be used from (among others) Python. If you're interested in examples, see for instance https://build-system.fman.io/pyqt-tutorial (I'm the author).
Qt is a great toolkit and I've messed around with it on Android on and off since Lighthouse. One thing I want to point out is that Qt is LGPLv3 and (in my non-lawyer opinion) this is a pain point on restricted application environments like the Google Play store on Android. Its not clear to me that you can comply with a user request to get access to replace or modify LGPL'd software in your application.
> Its not clear to me that you can comply with a user request to get access to replace or modify LGPL'd software in your application.
It doesn't need to be available via the same mechanism, it just needs to be available, no? And if so, you could embed within the .apk (even if it makes it huge), no?
I've been looking for a way to write cross-platform apps without a painful language or build hell, and I've just come across EQL5-Android, which binds Qt for Android with Embeddable Common Lisp. I don't know Common Lisp, but I like Scheme and I'll try anything to avoid Java or C++. So far it's looking very slick...
You may be also interested in my hobby project, a WIP tool for writing Android apps in Nim, completely without Java and/or Android Studio: https://forum.nim-lang.org/t/4840. I'm slowly pushing it further since the initial PoC announcement above, but it's not yet there for a second phase of loud publicity. Still, you may like to watch for releases on GitHub. As you can see from this project, I'm also desperate to avoid Java or C++... ;)
> The user of your application has to be able to re-link your application against a different or modified version of the Qt library. With LGPLv3 it is also explicitly stated that the user needs to be able to run the re-linked binary on it’s intended target device. It is your obligation to provide the user with all necessary tools to enable this process. For embedded devices, this includes making the full toolchain used to compile the library available to users. For parts licensed under LGPLv3 you are obliged to provide full instructions on how to install the modified library on the target device (this is not clearly stated with LGPLv2.1, although running the application against the modified version of the library clearly is the stated intention of the license).
Using the LGPL licensed Qt on Android looks difficult. Although, I suppose compliance would not be much work in comparison to the development of a significant app.
Has anyone else had to go through compliance with the above? How did you do it?
If you were to make a list, building the damn thing would probably come last. Go to the store on your favorite platform, search "The Qt Company" and try some of their demo apps.
It's all complete dog. Looks terrible, behaves worse. It's like Flutter except with 1/100th of the developer firepower to make sure it behaves natively.
My personal favorite is the input controls. They haven't freaking implemented copy and paste! It is all just beyond unusable.
78 comments
[ 4.3 ms ] story [ 185 ms ] threadhttps://pyre.chat
One fork of Pyre does this using a web view, and it fixes the media scaling bug, but what is the advantage over Signal Desktop at that point (besides being a tray icon & having native integration)?
Edit: Capitalization
- https://doc.qt.io/qt-5/android.html
- https://www.qt.io/
> Qt for Android enables you to run Qt 5 applications on devices with Android v4.1 (API level 16) or later.
> One framework. One codebase. Any platform.
Qt is amazing and so is QML. I still found QML JavaScript engine utilizing a lot of memory back then as well and I don't know if it has been fine-tuned these days.
Also QML will gain type checking.
TL;DR : "we’re aiming to have Qt 6.0 ready for a first release by the end of 2020."
I think I finally understand why everyone keeps saying that Qt on Android "isn't ready for prime time."
I have yet to use electron tho... I haven't done a personal project in a long time to play with it.
I had troubles accessing external storage (the SD-card), and ended up writing quite some ifdefs to fix that. Probably the kdab folks have proper solutions to most common issues, but at the end of the day the idioms between desktop apps and mobile apps are quite different, and you will end up wasting time to fix those issues if you really believe in having a single code base for cross-platform apps.
So I ended up keeping the logic in C++ with native views.
Felgo sells Qt components etc (no experience with them), they have a showcase: https://felgo.com/showcases
Now I wonder if someone has made a big scan of apps from Play store analyzing what toolkits they use.
This update looks really neat, and may solve some problems for some people. But personally my biggest gripe with Qt is qmake.
When you are doing Android, lots of resources assume Gradle, and lots of Qt stuff assumes qmake. Neither is ideal if you're dealing with other libraries like gstreamer, or even worse: proprietary libraries compiled using an old NDK.
So I ended up writing my whole build system in cmake, which made builds on Windows and Linux a lot saner, but made Android a living hell. I'd love to see better support in Qt for actual sane build systems you can use with real world third-party libraries, because qmake is not it in my experience.
The tooling for Qt needs help, I feel like this is a huge reason why shovelware Electron apps are so common now.
Edit: Capitalization
I think the pain is unfairly attributed to Qt. A lot of the pain actually comes from the poor tooling in the C++ world.
Conan is supposed to come to the rescue, but after attempting to use it, it feels like it's still not as easy to use as any other package manager (npm, pypi, gems, etc). I love C++ and Qt, but It's extremely difficult to convince people to start any new projects in C++.
Common C/C++ questions and answers in stack overflow: how do I do x in C++ (e.g. trim whitespace), the usual responses: 1. It's trivial to implement, do it yourself. 2. Why would you want to do that.
Compare that to pulling up a library to do that, or it's already baked into the standard library (e.g. Java).
That being said, my SO would love you! He is always trying to get me to write things in C :D
std::string is laughably underpowered in comparison - it's basically a vector of bytes, missing a huge amount of convenience methods and all Unicode support.
The XCode cross-compile is incredibly smooth, and the runtime is complete ass. Qt really messed up high-DPI support and it has no better example of this than iOS.
It started, but then it crashed. So I gave up on that, and let someone compile it directly on Windows. Then there are no issues.
I did not try Android there.
Then I have another app that runs on Linux, Windows and Android using FreePascal/Lazarus rather than Qt.
FreePascal is really great for building. You only need to set the search path, and then it finds all the files it needs (just sometimes it crashes when serializing the dependency graph, then you need to delete all object files and restart).
Cross compiling from Linux to Windows works perfectly. FreePascal has an internal linker, so you do not need any other software for Windows. You do not need to deal with proprietary libraries, because there basically are no FreePascal libraries, especially no proprietary.
Linux-Linux cross compilation is more complicated. I just got a new computer and my 32-bit build failed silently because I did not have 32-bit gtk dev files and crtbegin from gcc installed. Yesterday I tried to install them with apt, but the installation failed, because they were conflicting with the 64-bit gtk dev gir files. Then I set force override in apt, and the installation worked, and then FreePascal cross compiled correctly. However, today I noticed, apt had uninstalled Python, Mercurial, Tortoise-Hg and most TeXlive packages. There must be something very wrong with Ubuntu's multiarch support.
There are three ways to run a Lazarus GUI on Android. First LAMW which has created a lot of FreePascal JNI wrappers around Android Views (and is far too complex for my liking); secondly Lazarus Customdrawn which draws all controls directly in FreePascal (and looks like it was designed to be Windows 98 compatible and crashed) and thirdly Qt, because Lazarus supports Qt as GUI backend (which probably works on Desktop, but I do not know anyone using it on Android). Hence, I compile my app as .so, export the data through JNI, and wrote a completely new GUI in Android Studio without using anything of Lazarus. Gradle does not need to know anything about FreePascal, it just copies the .so to the apk. But theoretically Lazarus is all you need. (Then I tried to submit my app to F-Droid, but they cannot include FreePascal/Lazarus apps, too complex build process)
Does mean you have a platform specific build system though.
[1] https://openjfx.io/
[2] https://github.com/cljfx/cljfx
[1] https://tornadofx.io/
you haven't seen QML :-)
http://qmlbook.github.io/ch04-qmlstart/qmlstart.html#qml-syn...
https://en.wikipedia.org/wiki/JavaFX
OpenJDK is now the 'official' JDK and reference implementation with Oracle making proprietary forks for their own customers, supported on their own timelines.
Java is actually doing some really interesting things since Java 9, with modular runtimes, pluggable garbage collectors, new compilers (Graal) and the Clojure crowd are being swept along with it simply by stint of being on the JVM.
> The requested URL /pyqt-tutorial was not found on this server
5 missing
If you had a negative experience with Qt for Android, go ahead and share it.
That's the only way to legally distribute Qt apps through Apple's app store.
It doesn't need to be available via the same mechanism, it just needs to be available, no? And if so, you could embed within the .apk (even if it makes it huge), no?
https://gitlab.com/eql/EQL5-Android
Source: https://www.qt.io/faq/
Using the LGPL licensed Qt on Android looks difficult. Although, I suppose compliance would not be much work in comparison to the development of a significant app.
Has anyone else had to go through compliance with the above? How did you do it?
https://www.qt.io/start-up-plan/
I thought there was a small business license available for a one-time fee of $100, but now I only see recurring subscription options.
It's all complete dog. Looks terrible, behaves worse. It's like Flutter except with 1/100th of the developer firepower to make sure it behaves natively.
My personal favorite is the input controls. They haven't freaking implemented copy and paste! It is all just beyond unusable.
What are you talking about? Qt Widgets and Qt Quick Controls (QML) have always supported copy and paste.