Qt 5.15 Alpha | Hacker News Reader

Qt 5.15 Alpha

qt.io

69 pointsturrini34 comments

For HN why this release is important:

* Qt essential killed LTS for non paying customers starting with this release (but Qt stills stays GPL/LPGL and Commercial). You still will be get these fixes but only in the next minor version [1]. Personally this is not really an issue for me (nether for my open source app ScreenPlay nor for the Qt app I develop at work) because Qt is fairly stable.

* Last release before Qt 6

* You now need a Qt account to download (via the maintenance tool) _any_ Qt libraries from qt.io. Why does this remind me of docker?

[1] https://www.qt.io/blog/qt-offering-changes-2020

LTS: Long Term Support

To that list, I'd add:

* Qt is a pure joy to work with compared to every other cross platform widget toolkit out there.

Over the years, I've worked with gtk 2, gtk 3, Tk, wxWidgets, SWT along with proprietary toolkits like MFC and Cocoa. Qt stands above them all in terms of ease of use and quality of output(among the cross platform).

Putting the LTS as your first bullet makes no sense to me. Developers are not cheap. Qt does not owe companies the engineering resources to support and maintain an LTS product. All of their code is still open source and development in the open, working with their community. (I've personally found the paid developers very responsive to issues I've raised.) So if Companies aren't paying for Qt, who should? If that minor change helps keep Qt alive, I'm all for it.

* Last LTS release before Qt 6

It didn't get any traction on HN at the time, but I thought the following blog post about Qt offering changes, from a long-time Qt user, was excellent:

https://valdyas.org/fading/software/about-qt-offering-change...

HN thread: https://news.ycombinator.com/item?id=22177821

huh, is AudioMulch done with Qt ? :)

I'm a solo developer of 3 commercial Qt applications:

https://www.easydatatransform.com https://www.hyperplan.com https://www.perfecttableplan.com

I won't be eligible for the 'small business' plan as my revenue if over the threshhold they specify. And their full plan is crazily expensive. So I guess I'll be sticking with LGPL.

Honestly, I think at this point we'd be best off discouraging use of Qt once and for all. Their licensing shenanigans have been causing all kinds of issues, and have done so for literal decades. It's fairly clear to me that they're not reliable in their licensing decisions.

I believe they have ended up with a freemium model where some big companies are paying them heaps, but the vast majority of users are paying them nothing. It must be a tough way to run a business. Especially one with loads of expensive software developers to feed.

I used to have a commercial license that was around £1k per year. But when they offered LGPL I moved to that. I haven't paid them since. And now the commercial licenses are much more expensive. You wonder they could come up with something that people like me would pay ~£1k per year for.

I really hope Qt company doesn't go bust.

Absolutely correct. I am a small commercial developer, I would gladly pay USD $500/yr. to insure Qt carries on.

I have come to the startling realization that, having converted to Qt, I am now 99% Win32-free. And I get a free pass to UWP (the OS/2 of the 21st century) should I need it.

$500 per year is a small price never to have to read Microsoft Win32 documentation. ;0)

Seriously you would wonder that the Qt company can't offer something attractive to solo developers and small companies around the $500 to $1000 per developer per year mark.

What makes it complicated to judge their pricing policy, and may explain why different people have such contrasted views on this, is that many of us need Qt for very basic things only (reasonably portable set of widgets for simple desktop apps) while a few industrial users have rare but imperious needs (such as support for fancy animations, modern or custom look and feel, support for embedded devices, professional hot line, IDE with support for enterprisy workflows etc). What I need Qt for requires very few engineers, just enough to maintain the same set of widgets that were already developed 20 years ago for most of them. Rather than paying a license I would use a Qt fork such as https://www.copperspice.com/ or use gtk or wait until revery is ready.

Should they donate qwidgets to a foundation I might consider contribute code and fund, though.

I would use a Qt fork such as https://www.copperspice.com

I can see your point. However, who knows what crazy curves Microsoft or Apple are going to throw into their O/S'es in the future? I would still feel safer depending on a team of full-time, paid, commercial engineers to stay abreast.

Qt has got really big and I probably only use 20% of it. But the 20% I use might be quite different to the x% you use.

Also Apple likes to nuke its developer ecosystem from orbit every 5 years. Qt struggles to keep the Mac classes stable and working in the face of this. I'm not sure an unfunded open source team is going to do any better.

They've been losing money, but it seems both their revenue and their staff has doubled in the past few years. I was surprised, but they actually look reasonably healthy.

The only thing that matters license wise for 99% of people is https://github.com/qt/qtbase/blob/dev/LICENSE.LGPLv3 which cannot be changed without renegotiating with KDE.

Yes but they can add commercial and GPLv3 only modules. Like they did with Qt Charts.

... so what ? other companies can also write Qt libraries under GPL and commercial licenses if they wish to - why shouldn't TQTC be able to do the same ? It does not make the rest of Qt any less LGPL.

For reference, on arch linux, there is a grand total of 3 packages with a hard dependency on qt charts, one of those being a python binding to it. versus the whole of KDE plus a ton of other things that have no problem depending on "just" the LGPL parts of Qt.

So what will we use? Electron?

Developing a massive professional grade UI library and platform is a monstrous undertaking. Who is going to pay for it? The alternative is for it not to exist.

Qt is all of:

- GPL since 2000

- GPLv3 with special exception (convertible to MPL, etc.) since 2005

- LGPL since 2009

It took me 10 minutes to find this out. Please be more responsible.

It's off-topic, but I would like to thank you for your blog[0], I really like how open you are about your journey.

[0]https://successfulsoftware.net/

Thanks. Would like to blog more. But it is tough to find the time with 3 products!

Can someone explain what is the issue with LGPL license? Do you plan to modify Qt code and add your proprietary secret stuff in it? Or you want to build one big binary proprietary blob? (what I liked about Qt it that is has been split in chunks so you can avoid depending on the entire framework if you just need the core.

The App Store explicitly forbids LGPL code.

Sounds like an Apple problem, not a Qt problem.

That has not been the case for a few years, there are LGPL / GPL apps there again. (The issue was that you had to pay to upload a modified version of an app to your own device but this is not true since xcode 7 and we are at xcode 11...)

It's unclear if you can fulfill the LGPL license requirements on locked down platforms like iOS.

I don't think the complaints there are well-justified. Buy the proprietary license for proprietary platforms. If you're already paying Apple for a developer account, the issue is really a matter of money, not principles.

"...low price ($499/year). This price includes the use of the full Qt for Device Creation product, but not any distribution licenses – these need to be agreed separately."

What does this mean? I can download Qt and develop an app, but I can't give it to customers?

I think 'Device Creation' applies to something to do with embedded products, and won't apply to 95% of Qt developers. But I could be wrong.

Qt for device creation is when you want to create an embedded device (medical hardware, car dashboard, TV screen, etc). It is fairly irrelevant for anything that runs on desktop, mobile or even simple embedded such as Linux on a RPi.

I don't have much experience in the world of UI/cross-platform, so the following question might have some obvious answers, however:

Why would someone opt for, say, Qt to design an app, when they can develop something in browser and have that run cross platform?

(My guess is that the browser is insufficient for power users / sophisticated use cases.)

First you'd need to work out why someone would develop a desktop application rather than a browser-based application. Even once that's resolved it is not a given that you'd choose Qt.

Factors that might weigh in favour of developing a desktop application:

Some applications expect access to native platform features -- for example audio IO, or custom data acquisition, or access to native hardware capabilities, or last-20% performance. Although there are workarounds to access this kind of stuff from a Web UI, sometimes it is considered easier to just write everything in one platform-native language. Obviously over time some of these technologies come to the web (e.g. Web audio, WASM) but some people prefer to program a real machine, not a W3C specified VM.

There is a perception that web or Atom applications use more resources than a well tuned C++ desktop application. If your application is already resource intensive then putting a resource intensive web UI on it doesn't necessarily make sense.

Personally I have the perception that web technologies are too volatile to take a long term bet on. I don't consider that rewriting my application every few years is a good use of my time. That said, the release churn on Qt is now way too high for my liking.

I wouldn't underestimate the "If all you have is a hammer everything looks like a nail" mindset -- if you're a C++ programmer, developing a desktop / Qt application might be more appealing than using web technologies. Of course it goes the other way too.

Once you've determined to make a desktop application, then you can ask why you would use Qt for cross-platform UI (note that there are other reasons to use Qt, such as for embedded UI).

No doubt your "insufficient for power users / sophisticated use cases" is sometimes applicable. But I think this is mostly related to "native desktop app" vs "browser-based" rather than Qt / not-Qt. There are many cross-platform desktop applications that choose not to use Qt.

So you really have to look at the problem Qt deals with. UI APIs on each platform are radically different: no matter how you approach it, cross-platform UI requires a portable UI architecture, and Qt provides this architecture off the shelf.

Qt also provides a whole lot of other frameworky stuff that you may or may not want or need. It's a one stop shop.

Some application developers want something close to native look-and-feel but want to outsource-cross platform UI (a kind-of write once, run everywhere, at least for the UI). In this sense Qt is one of the middle options in the "Native / cross-platform / web" continuum.

That makes sense, thanks for taking the time to write that up.

omg! moving to flutter.

Reply on news.ycombinator.com