Qt for Android better than ever before | Hacker News Reader

Qt for Android better than ever before

kdab.com

115 pointsjcelerier76 comments

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.

Qt development using Python is similarly painful, I end up drafting things up in Qt Creator, taking that code and amending it to work in Python.

The tooling for Qt needs help, I feel like this is a huge reason why shovelware Electron apps are so common now.

Edit: Capitalization

It's Qt not QT

Edited both comments, should be fixed now

I've been developing C++ for 10+ years.

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

QString::trimmed() ;)

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.

I read somewhere a few months back that qt is dropping qmake in favour of cmake in the medium term. And everyone rejoiced.

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.

That's a step in the right direction. The next thing would be to drop the compiler extensions (signal/slots macros) in favor of modern C++.

Already done by CopperSpice.

Verdigris is a moc replacement (not a Qt fork like CopperSpice) which generates QMetaObject through macros using constexpr.

There is sadly no reflection nore code generation yet in C++ so that cannot work without lots of ugly macros.

You didn't try iOS? =)

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.

There is already CMake support in Qt, and Qt itself is going to be compiled with CMake starting from version 6.

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.

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

https://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

What about qml?

Why not GTK? You have even less bloat than in qt.

GTk has zero out of the box support for mobile.

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

https://gitlab.com/eql/EQL5-Android

when i saw the article my first thought was to wonder whether eql was still alive. nice to know that it is!

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++... ;)

Dart+Flutter can do cross-platform desktop, web, android and ios.

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.

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

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

Qt6 will have faster and lower footprint QML because JavaScript will be optional.

Also QML will gain type checking.

Is there a timeline or target release date for Qt6 yet?

https://www.qt.io/blog/2019/08/07/technical-vision-qt-6

TL;DR : "we’re aiming to have Qt 6.0 ready for a first release by the end of 2020."

Thank you! I read that page, but I guess I didn't read it properly.

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.

> I know it was quite a hassle to create background services

I think I finally understand why everyone keeps saying that Qt on Android "isn't ready for prime time."

Could you do a comparison of why using QT js instead of electron/ionic?

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.

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

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?

Typically you get a commercial license for mobile development. That's the only way to distribute Qt apps through Apple's store.

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.

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

> Not Found

> The requested URL /pyqt-tutorial was not found on this server

https://build-system.fman.io/pyqt5-tutorial

5 missing

Your link is broken.

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.

That issue goes away if you purchase a commercial license, which is quite affordable.

That's the only way to legally distribute Qt apps through Apple's app store.

Thankfully it's a one-shot license for "mobile" development as opposed to "embedded" development, which needs a paid license per unit.

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

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.

[1] https://openjfx.io/

[2] https://github.com/cljfx/cljfx

You can write in C++ so it's much easier to re-use libraries in C/C++.

Electron does allow to use c++, what make QT c++ more practical for business logic?

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

Thanks for exemplifying! Nit: filesystem is fixed in C++17.

I’d add that passing objects is also way easier when you do not need to bridge languages. And you avoid gyp.

Along the lines of [2], there is also ScalaFX: https://github.com/scalafx/scalafx

And TornadoFX[1] in Kotlin, which seems to be a complete framework.

[1] https://tornadofx.io/

> It can also be written in React-like declarative style[2], which is much easier to maintain.

you haven't seen QML :-)

http://qmlbook.github.io/ch04-qmlstart/qmlstart.html#qml-syn...

QML is declarative and you don't need to use Clojure to use it.

No Oracle dependencies?

JavaFX as of JDK 11 (the next LTS after JDK 8) is now part of OpenJDK. It's still released separately, rather than integrated like Swing is.

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.

For those new to hearing about Qt / Qt for Android:

- 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 for Android has always looked pretty good but I never see it used. Could someone link a few real-world apps developed with Qt for Android?

Same here. Would like to see some real world apps and ideally also the code.

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.

That was my experience back in Qt 5.4 (so a while ago).

So I ended up keeping the logic in C++ with native views.

The KDE project has a few, some of which are Desktop and Android: https://play.google.com/store/apps/dev?id=475889458590528766...

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.

That is great, love it how sometimes things like this are stumbled upon by working outside what you are used to.