We have a website presence too, and the website UI (as visited in a normal browser) is 95% the same style and functionality as the desktop app.
So when you browse to our site via the desktop app, certain OS-only features turn on.
So it made a bunch of sense to use QtWebkit. I welcome the switch to QWebEngine though, if for nothing else in the hopes that the underlying browser code gets a update and the app will hopefully then feel more responsive.
Atm we use a mix of QtQuick/QML and some widget code mainly when wrapping QtWebKit it for some parts of the app furniture that need it.
Although the guts of our app requires native code (for clipboard monitoring and websocket message receiving), were considering ditching much of the UI in favour of a webapp.
Can you comment on your experience? One of my doubts is if I should go the QML / Qt Quick Controls way or the standard Qt Widgets (with PyQt).. For instance, do you think you could implement your app's interface with Qt Widgets by itself?
The problem is that I know how far I can go with Qt Widgets, but on the same way, I would like to build something more "modern" and Qt Widgets may be quite limited..
I could have implemented it with QtWidgets, however I had found a decent UI widget library that suited my use case very well ([1]). Hence went with QML/QtQuick.
My advice - just do it :-). If you want to build a cross-platform desktop app then go for QtQuick/QML/C++. QtCreator has a bunch of example projects. Use those as reference. The Qt docs are solid. Worst case - you will learn that Qt/C++.
I am not a big fan of PyQt/PySide, especially when starting fresh with Qt - you would have a hard time figuring out how everything fits and where the issues are.
I have used web-based task/todo lists (trello, asana, etc.) but I wanted something that could be used offline - my work does not allow storing company sensitive data on 3rd-party servers.
Started the project with Electron, using AngularJS and Angular Material. That allowed rapid prototyping with a slick UI and it was fairly easy to find additional Angular-based plugins. My main motivation in selecting Electron and Angular was to learn the two technologies (easier to learn something by doing a project in it). Screenshot: http://imgur.com/NZzEFKX
Had a few issues with the Electron app - big download size (50-70MB zipped), no print functionality, app felt non-native, very convoluted process to get it published on the Mac App Store.
Decided to change the tech stack to Qt/QML. I have published C++-based games, built on Cocos2dx. Wanted to try Qt to build a serious app.
Gumroad has been a slick experience - I have opted for the fully functional trial option and let the user buy a license to use beyond the trial period. Gumroad's onboarding (buy workflow) and tech (license key generation and validation) have been a revelation.
Qt has both commercial and LGPL licenses. I think you can develop commercial applications with LGPL and not distributing the source code of your own app, but you can't statically link to Qt's libraries. https://www.qt.io/qt-licensing-terms/
That's not correct. You can use the LGPL version of Qt to develop commercial product without paying for a license and while keeping your source proprietary. You aren't allowed to statically link Qt under LGPL, but that isn't a big deal.
So when you browse to our site via the desktop app, certain OS-only features turn on.
So it made a bunch of sense to use QtWebkit. I welcome the switch to QWebEngine though, if for nothing else in the hopes that the underlying browser code gets a update and the app will hopefully then feel more responsive.