Qt 5.9 LTS released
blog.qt.io
blog.qt.io
Some regressions introduced by 5.8 (some wayland related) aren't fixed yet and Qt WebEngine does not build on AArch64.
There is a bug that breaks applications using kdialog horribly and in the 5.9 branch (to-be 5.9.1) there's already a change that changes behaviour in a (incompatible with the 5.9 doc!) way that breaks some existing applications.
At least they can't make any excuses to not release 5.9.x releases this time...
That was fixed in the 5.8 branch. I wonder why the fix isn't in 5.9.
Disclaimer: I'm only a passersby, these are informal feelings based on observing the Qt world.
eg if you've built a client application which runs on OSX, calling the verify() function on the cert returned by a server just prints "Unimplemented code." on stdout/stderr.
https://bugreports.qt.io/browse/QTBUG-56973
Not totally sure how to work around that before its fixed, but kind of thinking maybe running some openssl (etc) commands on the client might do the trick. Focused on other stuff atm anyway, so haven't really thought about it in depth. ;>
If we do that, we'd be able to make OSX versions of our app instead of having to do some dodgy "validate the cert using direct openssl calls" approach. That definitely sounds workable.
I'm going to stop looking at that QSsl API. It looks very poorly designed.
The server side code is taking most of the effort, so we'll return to the client side bits later when we have something more solid (less changing) for it to talk to. :)
Our desire is to make sure the server we're connecting to is "one of ours". eg to validate the cert provided by the server against a cert chain we've bundled with the client just for this purpose
The docs for the function seem to indicate that what it's for.
Er... suggestions/assistance (etc) on what we should be doing instead are definitely welcome. :)
From someone named tartbooger?
auto verificationErrors = reply->sslConfiguration().peerCertificate().verify(m_sslConfiguration.caCertificates());
That's a reasonable (and necessary) thing to do, but the "verify" function doesn't do that. It's a static function, thus it ignores "peerCertificate". The way you're using it, it simply verifies "m_sslConfiguration.caCertificates" using the system's default CA certificates (I think; the docs are somewhat confusing about this).
Also, further down in that code, you ignore self-signed errors. Well that pretty much negates the point of checking in the first place doesn't it? Because if someone MITM's your connection with a self-signed certificate, your code will say that's fine.
However, according to the docs for "QSslConfiguration::setCaCertificates", those CA certificates are used to verify the peer certificate during the SSL handshake. So do you even need to be doing any kind of verification manually? I'm not a Qt programmer, but it seems to me that since you're using the appropriate "QSslConfiguration::peerVerifyMode", it should verify the server certificate during the handshake using the CA certificates you set (it happens in the Mac code at [1]).
Bottom line: your "RemoteDatabase::gotEncrypted" function can simply be eliminated. This would both provide proper peer verification and eliminate your problem on the Mac platform.
[1] https://github.com/qt/qtbase/blob/dev/src/network/ssl/qsslso...
Awesome! Thank you. :)
After investigating further, it seems that doing manual verification is unnecessary, since Qt does verification during the handshake so long as the default verification mode is used (or the setting to force both server and client verification is used).
We're creating a "cloud" (will be at https://dbhub.io) for people to share/store/collaborate/publish/etc data in SQLite format. Kind of niche, but it should be really helpful for places needing to version+collaborate on (non huge) reference data sets.
There's a live dev server here if that's of interest:
https://dev1.dbhub.io/justinclift/Belfast%20Bikes%20Docking%...
Note - that page shows the expected look and feel. We have no real front page at the moment - it's just a list of public databases that have been uploaded for now - but that'll change as some other bits are completed. :)
[1]: https://fman.io
[2]: https://fman.io/blog/picking-technologies-for-a-desktop-app-...
Generally PyQt for the little ones and then full C++ for the mode complex ones.
There's only really wxWidgets in this space, which is order of magnitude smaller.
I guess on Windows there's .NET if you don't care for other platforms as much. Do people still use other toolkits for writing native C++ apps with GUIs? MFC? Native win32 code?
I'm convinced that the time I spend on working around its age and oldschool architecture is less than what I would have spend had I switched/"upgraded" toolkits every 3-5 years as seems to be the common practise. Same goes for using C++, btw.
I really only know the ones I mentioned!
The framework is very solid, the components are easy to combine and in general, once you get used to it, it becomes quite easy to work with them. The resulting app is very performant and has low memory consumption in comparison to JS-based apps. Also, adding asynchronicity is actually not hard, at least for things like HTTP requests, as you can use Qt signal/slot system to receive events asynchronously so that in simple cases it is not necessary to mess up with threads.
However, the developer productivity is, in my perception, is a somewhat less than with modern JS frameworks. Not 10x less, but a bit less. I think one of the issues is C++ itself: after changes in the code, it is necessary to not only rebuild but rerun the app, and in general writing C++ code is something that requires some attention as otherwise, it is possible to have SEGFAULT somewhere in your app and then spend time looking for the place in your new code that causes this SEGFAULT.
Note that I'm talking here only about classical QtWidget/C++ apps, not QtQuick ones. I think productivity with the second ones should be better. However, one might argue that if you started to write your code in Javascript, it's better to do it in a way that allows you to have the same code running natively in browser (QtQuick experimentally runs in it, but it is experimental and not mainstream), so that you can share components and code for example between your site and your desktop app.
When I write the PC side of the system I can usually port the necessary support code right out of the embedded project in a few minutes.
I'll also build PC versions of the embedded GUIs for sales demonstrations. My sales team loves that.
EDIT: also, it's LGPL or $80/developer-month, not and. I don't see anything about royalties. And considering the GPL doesn't apply until you start distributing the software, you don't need to spend that money during development. You can wait to license when you release and start getting revenue.
This was quite a confusing policy in some ways. I think in practice they expected to resolve such situations by backdating payments for the commercial licence to cover the development period.
(Edit: from https://www.qt.io/faq/#_Toc_3_13 it looks like the policy is unchanged but the wording around it has been softened a bit to encourage negotiation)
Or that you develop for 12 months and get a commercial license the last month,, when its going to be released.
The important part is once you realize you have the wrong license you contact sales admit your mistake and make a good faith effort to correct things.
That's for Qt for Devices. Conditions aren't public, but: "To learn about Qt for Device Creation pricing – developer licenses and embedded device distribution fees – start the conversation now"
also, it's LGPL or $80/developer-month, not and.
It's actually more like $300/dev/month unless you qualify as a startup.
Last time we quoted for our smallish product (1-2K EAU), Qt wanted $5 or $6/unit, purchased in blocks of 1,000 licenses at a time. That was too much of a hit on our BOM, so we went LGPL and haven't looked back.
I wish there was a FAQ with easy answers like "If you write an iOS app with Qt, you can close the source if you pay us a license fee" or something along that line.
IIRC, Xamarin had similar problems, but that went away when they were purchased.
No, only "re-link-ability" is required, thus you can dump only obj files somewhere.
They don't make FAQ about this, because they don't want to publicly state that it is possible to use free Qt for commercial mobile apps.
It suggests that LGPL + iOS app store is not OK, but doesn't fully explore why not.
Edit: Ah yes it does say:
> For the time being, the Configuration UI Tool is a commercial only tool, that adds value for our Device Creation customers.
Oh, this is pretty awesome! I was running into issues updating an old Qt program with QPainter a few days ago, this is super timely.