[xpaulbettsx]

I'm not sure I buy that, are you saying that the only reason that Qt hasn't completely taken over writing native software on (even desktop! not to mention mobile where Qt also works), is a marketing problem?

I would argue that Qt's problem is:

* Licensing is expensive (look it up, you can't just use it for free for large-scale commercial projects, contrary to what many people believe)

* Getting started with Qt is painful and integrating it into an existing codebase even moreso - get ready to suffer with C++ linker nonsense

* You have to write in languages that are not particularly enjoyable to ship a production application (C++, JavaScript but without The Nice Parts of modern JS web dev)

* The "deploy" bit is completely left to the reader, Qt doesn't help you write apps and ship them end-to-end. Contrast this with Electron which has a pretty strong (albeit a bit mysterious) packaging and auto-update pipeline

Qt experts will argue on all these points, "It's a library, it shouldn't do XYZ", but at the end of the day, Qt is a means to ship Desktop and Mobile Software, and by ignoring the entire Developer Experience from end-to-end, they miss the mark.

[freedomben]

* Licensing: IANA lawyer, but my understanding is that the LGPL doesn't force you to release the entire source, unless you are shipping a single static binary or a custom version of Qt. If you dynamically link, you are good to go.

* Getting started: I agree it is painful. There's a definite learning curve here. I believe it's worth it obviously, but that's obviously subjective.

* Language choices: There are binding for quite a few other languages. There's a lot of pyqt projects out there. But I disagree that C++ is painful - it really depends on who wrote it. Well written C++ is pleasant, poorly written C++ that abuses things is awful. The javascript portion does suck tho, you are right. It will improve, but it doesn't improve quickly.

* Deploy bit: you predicted my argument here. I favor the system package manager.

[elcritch]

Actually, you _can_ release a static binary if and only if you also provide all the components needed to re-link the static binary. Read part 1 of the LGPL FAQ section on static vs dynamic linking [1]. It's trickier on iOS and Android app stores due to the distribution method. IANAL, but at one point Apple had a (obscure) link to the object files needed to re-link one of their programs which linked to an LGPL library -- alas I can't find the link anymore.

Edit: To clarify, if you provide the parts of your application that are proprietary as statically linked libraries wherein the recipient can relink to a modified version of the LGPL'ed library then that satisfies the LGPL.

1: https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...

[shawn]

FWIW gamedevs have a natural aversion to anything with the term "GPL" in it. http://codesuppository.blogspot.com/2009/01/

Not saying it makes sense, just that groupthink is strong.

[pjmlp]

Games devs have aversion to the FOSS culture.

It doesn't play ball with IP business and NDA rules that are common place in the industry.

[pjmlp]

Licensing is quite cheap compared to other commercial products in the same league.

I find it quite acceptable.

- Willing to give your work for free the same way as taking Qt's work? No problem, LGPL has you covered.

- No issues with dynamic linking, still wanting to use the work of others for free? No problem, LGPL has you covered.

- What to sell it for lots of cash? Then give the Qt guys a piece of the cake back and be happy they still exist.

I wonder what are the nice parts of JS web dev, collecting new frameworks and build tools every week, or functions as packages?

In fact I am pretty opinionated that some of the new UI goodies are only exposed via QML, which wouldn't be a problem if people stopped writing logic there.

[ahartmetz]

The licensing bit is really trivial to summarize: It's LGPLv3. Formerly v2, so now it can't be used for free in some applications where it formerly could.

You can absolutely use it for free in any project, as long as you conform to LGPLv3.

Regarding JS: You're not supposed to write more than glue logic in JS - well, that's the practical experience. For some reason, the Qt company recommends more JS use than that.

[xpaulbettsx]

It's not though if you want to use Qt Quick

[ahartmetz]

What do you mean?

[anaisbetts]

The QtQuick compiler is only licensed for commercial use, according to their licensing page.

[slavik81]

QtQuick doesn't need to be compiled. That's just an optimization. I've never used it or needed it, though admittedly I haven't worked on massive QtQuick projects.

I think the main reason that's a commercial offering is that developers of proprietary software like shipping binaries instead of human-readable QML files.

[berti]

The QtQuick compiler is only needed if you want to optimize startup performance (by compiling assets to binary form in the build process). I've never needed it. I'm guessing you've never actually tried QtQuick based on your comment.

[beojan]

Not since 5.11.

[dakerfp]

You can use the Qt Quick without compiling though it slows the loading.

[Buttons840]

> You can absolutely use it for free in any project, as long as you conform to LGPLv3.

So you're saying there are projects where I cannot use Qt? The fact is, there exists projects that do not have the option of using Qt without paying for expensive licensing. Such projects should at least consider using Electron which might have significant non-technical advantages for them.

It is cool that what many consider to be the best commercial desktop GUI is also open source, I will admit that much. Still, we shouldn't complain too much when many projects choose to use Electron, it's licensing is just so much more permissive which is a significant advantage for many projects.

[pjmlp]

Yeah, right.

"I don't want to pay for software, so here take a bloated browser as fake native app".

[fsloth]

"Such projects should at least consider using Electron"

I don't think QT and Electron are architecturally equivalent.

[jcelerier]

> Such projects should at least consider using Electron which might have significant non-technical advantages for them.

Electron uses components that are under LGPL (Chromium for instance) so it's basically exactly the same license questions than with Qt.

[IshKebab]

You can totally use it for free in large scale commercial projects. Just link with it dynamically.

Deployment is a little bit of a pain but they actually provide software to help - macdeployqt and windeployqt bundle everything up into a dmg or a zip.

You aren't forced to use QML. I kind of hate it and QtWidgets are much more mature - I just use those. Sure maybe they aren't being developed so much but they're still maintained. I don't think they'll go away for a long time.

Qt is great.

[vram22]

>You can totally use it for free in large scale commercial projects. Just link with it dynamically.

Can anyone explain why it is free to use if you link with dynamically, but not statically? (I've seen this point come up a few times in discussions about Qt here on HN.) I know what dynamic and static linking mean, but not clear about the connection to free vs. paid Qt use. Is it something obvious that I'm missing? Only thing I can think of (admit I didn't think a lot about it yet) is that if you use it for free with dynamic linking, deployment is more of an issue, vs. just shipping a self-contained statically linked app.

Thanks in advance.

[jcelerier]

> Can anyone explain why it is free to use if you link with dynamically, but not statically? (I've seen this point come up a few times in discussions about Qt here on HN.)

long story short: it's actually false, you can entirely ship your app linked statically with Qt under LGPL and still comply with the license. However, you have to ship your .o files: basically, what the LGPL requires is for people getting your app to be able to relink your app with their custom version of the LGPL libs (so Qt).

[vram22]

Thanks for the reply.

[jcelerier]

> * Licensing is expensive (look it up, you can't just use it for free for large-scale commercial projects, contrary to what many people believe)

uh... yes you can. It's LGPL. Chromium and libchromiumcontent used in Electron are also under LGPL and this does not cause problems anywhere.

[IshKebab]

Here is a CMake example of deployment. It's not that difficult:

https://github.com/Timmmm/robocut/blob/master/CMakeLists.txt

[mherrmann]

All of the points you raise are solved by my open source library [1]. It's a Python wrapper around Qt that in particular solves the deployment problem. With it, you use Qt under the LGPL, and thus typically do not need a Qt license.

[1]: https://github.com/mherrmann/fbs

[giancarlostoro]

> Qt experts will argue on all these points, "It's a library, it shouldn't do XYZ", but at the end of the day, Qt is a means to ship Desktop and Mobile Software, and by ignoring the entire Developer Experience from end-to-end, they miss the mark.

Also they already build tooling for Qt such as Qmake and Qt Creator, it seems to me their goals are clearly to make those goals attainable, it may not be as perfect as the alternatives but it does do a decent job at the very least, but I do agree, the licensing does keep me away from using Qt usually just because I never know where a pet project might end me up.

[movedx]

> Licensing is expensive (look it up, you can't just use it for free for large-scale commercial projects, contrary to what many people believe)

I should look this up because Qt is something I've got my eyes on for small projects that could get big. On that note, are you able to define "large-scale" for me? Would a desktop app' interfacing with a remote API be "large-scale"?

> You have to write in languages that are not particularly enjoyable to ship a production application (C++, JavaScript but without The Nice Parts of modern JS web dev)

I'm looking at the Golang bindings for Qt (to implement my point above.) Have you considered it? Is Go something you'd consider?

[opencl]

It has nothing to do with scale, it's either LGPL or pay for a commercial license. The commercial licenses are not cheap- $459 per seat per month.

[kevin_thibedeau]

Qt devs need to eat too and they don't have a bunch of sugar daddies like Linus.

[fsloth]

QT is a developed by a corporation. I would presume most QT core devs are employees of that organization.

[slavik81]

That's more or less the story these days. Thiago Macieira (the maintainer for Qt Core) keeps stats on contributors.

https://www.macieira.org/blog/qt-stats/

[movedx]

Even so, that's EXPENSIVE! It rules out a startup I'd say.

[pjmlp]

No, it is actually quite cheap.

Usually software licenses for commercial development tools have a few more zeros, or not even that, forcing one to schedule a meeting with their sales people.

Before the FOSS movement, startups somehow managed to pay for their software.

[freedomben]

I would have agreed prior to the re-licensing to include LGPL, but startups can still jump in and ship a dynamically linked executable. If you truly need/want static linking tho, then you are right the cost is prohibitive.

[baq]

It should be peanuts if you have any revenue at all.

[rubyn00bie]

You'll need a license if it's not open source as far as I can tell...

I would love to use Qt but their licensing and terms just immediately kill it for me: https://www1.qt.io/faq/#_Toc_2_5

[mkl]

I think you misread that. For any use, you need a licence, and the possible licences to choose from are 1. Commercial, or 2. Open source (GPL or LGPL).

You can make commercial software using one if the open source licenses. (Of course; otherwise it wouldn't be an open source licence.)

[CamperBob2]

It's LGPL-compatible, though, isn't it? Can't you just wall off the Qt layer in a separate library, and release the source to that?

[freedomben]

IANA lawyer, but my understanding is that you are correct. The LGPL doesn't force you to release the entire source, unless you are shipping a single static binary. If you dynamically link, you are good to go.

[movedx]

Perfect for me: develop the front end using Qt (on an OSS licence) and Go, which is just a dumb data rendering layer with caching, and keep all the actual business logic server-side. I'll happily open-source a "shell" :)

[shmerl]

> You have to write in languages that are not particularly enjoyable to ship a production application

Qt with Rust is progressing well.

[mehrdadn]

My main problem with Qt is just that it doesn't feel native, it's as simple as that. This trumps all other problems like the fact that it's a bazillion exabytes and painful to set up etc.

[flukus]

It certainly feels more native than web/electron, swing, XUL, GTK and just about every other cross platform technology. It's about as good as you'll get without a native client for each platform, which will always be the best option.

The only other options is the hybrid approach which uses native widgets like wxWidgets, but this means you're limited by the lowest common denominator.

[roryisok]

I used to care about the native feel, but now as long as something has a good UI I don't really care that much. Case in point, visual studio code. The file menu is native and that's about it. The rest is html / JavaScript and it's a great interface. I don't care that the buttons don't match whatever OS theme I'm using. The web never has.

[Can_Not]

> Case in point, visual studio code.

I think most people consider visual studio to be an exception, not the norm. Whether or not visual studio's performance success represents what the typical developer should be expected to get when writing idiomatic JavaScript in Electron has probably not been fairly evaluated in the face of popular performance slugs like slack.

[roryisok]

I was talking about nicely designed non-native UX/UI. Why are you talking about electron performance?

[flukus]

> The web never has.

One of the best things to happen lately is reader view which does make a good chunk of the web match my theme. There's always been plugins, custom css, etc to work around this failing of the web.

[cm2187]

I don’t know if it’s a good thing that every website must look like a bootstrap website and every iOS app must have the same Color and menus, etc.

The only issue I have with non homogeneous UI is that it is often an opportunity for not so gifted developers to become creative in term of basic UX and we often end up with no obvious way to go back, non discoverable features and other UX fails.

[nurettin]

Delphi is almost as "native" as they get on windows and you still need to do a lot of extra work just to draw a checkbox on a grid.

Use of native controls and their benefits is greatly exaggerated and it all comes down to some murky-feely subjective opinion.