Is there Qt-app template in Material style for Android in source form?
Qt for Android better than ever before
61–70 of 79 posts
Re: Qt for Android better than ever before
#62Earlier quoted context omitted.
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
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 projec…
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.
Re: Qt for Android better than ever before
#63Qt 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.
Re: Qt for Android better than ever before
#64Earlier quoted context omitted.
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
Re: Qt for Android better than ever before
#65I 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. Neith…
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)
Re: Qt for Android better than ever before
#66No it's not.
You're being downvoted for making a contrarian comment with no substance.
If you had a negative experience with Qt for Android, go ahead and share it.
Re: Qt for Android better than ever before
#67Re: Qt for Android better than ever before
#68I'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.
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).
Re: Qt for Android better than ever before
#69I 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. Neith…
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 element in vsxproj instead of , similar for UI and RCC, etc.
Does mean you have a platform specific build system though.
Re: Qt for Android better than ever before
#70I 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.
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.