
Qt 5.15 Alpha - turrini
https://www.qt.io/blog/qt-5.15-alpha-released
======
Kelteseth
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](https://www.qt.io/blog/qt-offering-changes-2020)

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

------
RossBencina
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...](https://valdyas.org/fading/software/about-qt-offering-
changes-2020/)

HN thread:
[https://news.ycombinator.com/item?id=22177821](https://news.ycombinator.com/item?id=22177821)

~~~
jcelerier
huh, is AudioMulch done with Qt ? :)

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

[https://www.easydatatransform.com](https://www.easydatatransform.com)
[https://www.hyperplan.com](https://www.hyperplan.com)
[https://www.perfecttableplan.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.

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

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

~~~
rixed
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/](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.

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

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

~~~
wtracy
The App Store explicitly forbids LGPL code.

~~~
jcelerier
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...)

------
GnarfGnarf
_"...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?

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

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

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

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

------
tomerbd
omg! moving to flutter.

