[ownedthx]

We have a desktop application that uses QtWebkit for the UI.

We had no choice technically-we need to use audio APIs on Win/Mac to get our job done.

Based on my experience, I would not recommend building a desktop app unless there is a technical reason to do so.

Data storage, building installers, signing your app for target OS's, and dealing with auto-update are all technical problems that I'd prefer to avoid if I could. Building cross-platform code is also a pain and, while totally doable, will slow down a team that is not familiar with it, I think.

If I really needed to build a desktop app in the future, I'd investigate building building a headless app that hosts a websocket, and use the user's browser to connect to a localhost websocket to communicate with it. (i.e., a technical choice freeing my from Qt)

[aaronsnoswell]

+1 for using a wrapped-web stack approach. We've recently taken another look at the Electron/NodeJS/WebSocket stack - it allows you to build a native app using web technologies, even calling native (WinAPI) calls. This space has really come a long way recently.

[jventura]

Do you have the frontend entirely made in HTML inside the webview, or it is just a small component?

My application must draw one SVG chart, and the SVG support on Qt is quite bad although I can render my SVG there..

[ownedthx]

The frontend is all HTML inside of the webview.

We do have a tray icon too, though.

[pabloski]

Hi, if I can ask: "why QtWebkit instead of Qtquick?".

[ownedthx]

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.

[jventura]

+1, I'm wondering if anyone is using Qt Quick for productivity-like desktop applications?

[motti]

We (copycopy.com), do.

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.

[kidproquo]

I built Tasktopus[1] using QtQuick/QML/C++. Highly recommended. I built it on the LGPL version.

[1]https://gumroad.com/l/ADWm/tasktopus

[jventura]

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

[kidproquo]

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.

[1] https://github.com/papyros/qml-material

Paraphrasing a previous comment:

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.

[ausjke]

For anything-QT that is commercial you need pay and it's not cheap for small teams.

[pabloski]

Is QtQuick commercial? No GPL version?

[ausjke]

IANAL but if you're making commercial products you need pay for QT. You can use GPL etc if you're doing open source I assume.

[jventura]

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/

[kevincox]

IIRC some of the newer libraries are being licensed under GPL (unless you pay for a commercial license of course)

[hermitcrab]

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.

[anotherevan]

Does the LGPL deal with the fact that you actually pull in a lot of Qt code in the form in header files into your actual compiled binary?