QT

Just got QT to work and familiarizing myself with the framework.

My first reaction is, why signals? Aren't they just an OOP-bloated version of callbacks? Is it exclusively because of the dark ages when C++ didn't have first class functions?

* Qt has meta data available so you can do stuff that's like reflection to control signal/slot connections

* Signals/slots work across threads

>OOP bloated version of callbacks
>first class functions

What are you talking about? Lambdas are probably OOP under the hood (just functors or some shit Id imagine) and function pointers have always been there.

Signals and slots are just a useful paradigm like the Observer pattern. Don't read into it too much.

>why signals
This is how you use Qt.
Is it a problem for you in any way?

Okay, made a few GUI hello world examples, and got buttons to do basic stuff. Looking at generated files it looks like some serious metaprogramming is going on? As in, apart from generating C++ code from XML files, automatically recognizes methods with names that match the names of the QT objects?

Nope, got nothing against. I just feel lost in general as a newbie. It's like a whole world separate from more standard C++ with its own types that have Q in front of everything.

QT is one of those big overwhelming frameworks. Don't panic, it will all become very familiar after a while.

Yes Qt uses a meta compiler called MOC. Its been the source of a lot of (undue imo) criticism. Its used to implement things like reflection and features that C++ doesn't support or did not support in the past.

A lot of the stuff in Qt is there because of poor support in legacy C++. Qt even has its own data structures like QList, QVector, QMap, etc over the standard template library because back when Qt started out these things were of poor quality or just unavailable.

Even now I think Qt4 can be compiled without C++11 (not sure about Qt5)

Either way Qt is pretty great outside of the disgusting L/GPL licensing. I used to use it a lot and its the best GUI toolkit I've ever used.

>Either way Qt is pretty great outside of the disgusting L/GPL licensing.
Its dual-licensed. They have a proprietary option. Which has restrictions and which you will pay a bunch of money for. That's entirely fair, if you ask me, Qt does unto you as you would do unto your users. You want to gouge them with proprietary software, Qt gouges you with proprietary software. You want to give them GPL code, Qt gives you GPL code.

So the key idea behind the crazy metaprogramming is that I don't have to do any typing? Fill out forms in QT creator, and wiring up with the non-GUI part of my code is basically done by using method names that correspond to the names of my GUI objects?

>Aren't they just an OOP-bloated version of callbacks?
Well, they are a particular version of callbacks with several neat and convenient features working automagically on it. But yes, ultimately they are just callbacks.

>Is it exclusively because of the dark ages when C++ didn't have first class functions?
Pretty much, yes. If designed nowadays, I'm sure the signals/slots framework would use first class functions instead and become that much simpler and more elegant.

basically.
You can also generate the gui by calling draw functions in C++ if you like, but you don't have to.

I'm fine with the part of the LGPL that says (contribute back your changes)

But the other GPL wankery prevents deploying applications on closed platforms. You want to write a mobile application? NOPE! You want to do some embedded hotness? NOPE!

Nokia made Qt L+GPL when they owned it. A lot of the Qt contrib was done under the weak understanding that the lighter terms of the LGPL were the important bits.

On the old Qt-Project website which Digia killed they had official license discussions on the wiki which had all these reasonable terms laid out.

Important contribs were done against this backdrop, like the majority of the initial Qt on Android support which was done by an open source external contributor and not by official Qt devs

Then Digia took over and went full retard. They scrapped the old licensing guidelines and basically said "fuck you if you want to deploy on closed platforms, the LGPL doesn't allow that pay us $$$$ a month oh and we're licensing all new code under LGPL v3 which is even more hostile"

I'd be fine with giving them $ if they didnt charge an absurd monthly fee. Unreal Engine has the best proprietary licensing scheme. Democratized and negotiable if you are above a certain level.

I feel extra salty btw because I've helped fix a lot of Qt bugs and worked with a devs contributing my own time for mobile platforms, and then they made the drastic changes, killed qtproject, abandoned the friendly licensing guidelines and basically went full corporate.

>But the other GPL wankery prevents deploying applications on closed platforms. You want to write a mobile application? NOPE! You want to do some embedded hotness? NOPE!
Wait, can you elaborate on that? I was under the impression that you could do all that just fine.

So what is the magic smoke that does that wiring by name thing? Is it QMetaObject::connectSlotsByName(notepadClass); combined with the various all-caps macros I see everywhere?

>"fuck you if you want to deploy on closed platforms, the LGPL doesn't allow that pay us $$$$ a month
>I'd be fine with giving them $ if they didnt charge an absurd monthly fee
well yeah, charging money, as much of it as the market will bear, is the only reason for making your shit closed-source, isn't it?

You're trying to have it both ways. If you don't want to give away your code to others, don't expect Qt to give away their code to you. If you think they charge too much you're free to not buy it.

It's perfectly allowed to run GPL applications on a closed platform. It's free software, you can port it to any OS you like. Look at all the prominent GPL projects that have Windows builds. You just have to distribute the source code for your GPL licensed app.

What GUI framework DOESN'T use some variation of Events/Signals/Callbacks? How would it even work?

Elm, sort of. Or at least, you don't deal with any of that directly. You just provide pure functions and define an immutable state type, and it makes great-looking interactive GUI's for you.

QLabel *label = new QLabel;
QLineEdit *lineEdit = new QLineEdit;

QObject::connect(lineEdit, &QLineEdit::textChanged, label, &QLabel::setText);

It's that simple. You can even connect a lambda function if you want.

So stupid question, how do I link QT statically? Visual studio gives me errors saying that some object file is set for dynamic linking. Do I need to build QT from source?

>Do I need to build QT from source?
Yes.

>fuck you if you want to deploy on closed platforms, the LGPL doesn't allow that
But it does allow that. You just have to make sure to link it dynamically.

Once you get used to the signals there pretty useful for communication between threads