Qt LTS going to closed source | Hacker News Reader

Qt LTS going to closed source

lists.qt-project.org

12 pointspaulcarroty13 comments

The Register: Open-source contributors say they'll pull out of Qt as LTS release goes commercial-only

https://www.theregister.com/2021/01/05/qt_lts_goes_commercia...

The Free fork should do away with the "signals" / slots" / etc. macros immediately. They were an embarrassment from the first day, and have only got worse with time. In 2019 "Qt Company" actually, officially had the gall to ask the ISO SC22/WG21 C++ Standard committee to change the name of a Standard Library member function that one of their macros squatted on. (A: "Take a hike.")

Apparently there have been capital-letter versions (Q_SIGNALS etc.) for a long time, but they never managed to get the user base ported to them, or even fix their own docs, which still to this day advocate them.

The reason why no one uses the already existing Qt fork is because of the removal of signal/slots. Qt users don't want to use callbacks.

Literally nobody needs to remove signal/slots. They just need to replace them with Q_SIGNAL/Q_SLOTS.

No framework merits new core language keywords.

I'm too young to have ever used the signal/slot keywords, only the Macro syntax and the new instance/functioin_reference syntax, but I've seen this in a lot of legacy code. I'm totally ok with this.

Great, Qt 6.x isn't ready, so KDE and others can't use it. They have to run a fork if they want to fix some bug in Qt. I really wonder what's going to happen.

I sometime wonder why they even still bother with opensource

They are contractually bound to. If they don't release an open source licensed version, the KDE Free Qt foundation is entitled to release the last version under a BSD license.

I will add, though, that lately it seems to me Qt has acted as though they wished that agreement did not exist.

That is what I was referring to : the spirit is not there (hardly ever was fully there anyway to be honest, IMHO).

Also, why KDE still bother with the Qt company. Fork it, call Kt and be done with recurrent Qt Company controversies.

What I have heard is that they don't want to do it if they don't have to. The maintenance burden is HUGE, and KDE have little commercial support.

They did say so. For example, there is some bug in Qt 5.15, and what are they going to do?

Reply on news.ycombinator.com