
Qt 5.7 released - bpierre
http://blog.qt.io/blog/2016/06/16/qt-5-7-released/
======
_ZeD_
"This means that all the parts of Qt for Application Development that
previously have been available only to commercial users are now available in
the Open Source package as well."

omg YES! finally! I was waiting for years to use QtCharts!

~~~
mindv0rtex
Just curious - have you ever tried qcustomplot?

------
criddell
Does anybody have experience with other cross platform GUI toolkits that are
still actively developed? It's starting to feel like Qt is going to win it all
because they are enduring (and excellent).

~~~
gulpahum
libui [1] is a promising new cross platform GUI toolkit. If I need a GUI for a
small cross platform desktop app, I will definitely try it.

It uses MIT license, which means there is less headache for commercial
applications. It is also more lightweight. I have always felt that Qt has a
lot of unnecessary classes. libui has C api, but it would be easy to write a
nice c++11 wrapper around it.

[1] [https://github.com/andlabs/libui](https://github.com/andlabs/libui)

~~~
jventura
libui is a very interesting project but I find it still pretty much alpha:
good enough for playing around with it, but not quite ready for production.
However it is moving fast, so who knows its state in a few months.. Btw, I'm
slowly building a python wrapper (1) and accepting contributions!

(1) -
[https://github.com/joaoventura/pylibui](https://github.com/joaoventura/pylibui)

------
Aissen
With LGPLv3, the Qt company is sending a clear signal it's time to pay if you
want to use Qt in a device (the industry being clearly anti-(L)GPLv3). It
could be the chance for GTK, if they weren't also busy digging their own grave
:-/ [http://lwn.net/Articles/691131](http://lwn.net/Articles/691131)

~~~
joshvm
If you're fine with dynamic linking, then commercial development is still very
much possible (though you lose Qt Charts).

The only major pain is that you have to supply a copy of the Qt Source if
requested - the pain being that a link to the official repo is not enough, you
have to be in control of the code. However, I would imagine if you gave
someone the option of (a) downloading from the website or (b) paying postage
and handling for a disc with the same thing, that would satisfy the license.

~~~
distances
> you have to supply a copy of the Qt Source if requested - the pain being
> that a link to the official repo is not enough

I don't think this this is true. My googling is now failing me as I just get
results about linking of libraries, but I remember reading it's enough to
point to the source if it's unmodified in your application.

~~~
joshvm
[http://www.qt.io/FAQ/#_Toc453700716](http://www.qt.io/FAQ/#_Toc453700716)

The Qt FAQ specifically says that their copy isn't sufficient, but as you say
perhaps it only counts if you've made modifications (which would make sense).

------
reddotX
JIT support for WinRT, and 64bit ARM platforms in Qt QML, leading to much
better QML performance on these platforms

+1 for qml perfromance

~~~
smegel
JIT for declarative markup? Has that even been done before?

~~~
CarVac
QML has always had it, as far as I know. It makes for a little pause when
loading an application as the logic is compiled. I'm not sure what other
markup languages have done this, though.

They do have a Qt Quick compiler though which removes the need to JIT the user
interface; maybe next release it'll see the light of day on the open-source
side of things.

~~~
distances
As far as I understand it's a bit different trade-off: pre-compiled code with
no JIT means faster startup, but a bit reduced performance.

------
symlinkk
I want to like Qt but I hate that it needs moc. Also I don't like that it
doesn't use much of the STL - it forces you to use classes like "QVector" and
"QList" instead of std::vector and std::list.

~~~
RotsiserMho
I avoided Qt for a long time due to what I'd heard about moc being required.
However recent versions support connecting lambdas to slots which is
sufficient for my relatively simple application to avoid using moc to set up
signals/slots.

~~~
symlinkk
Do you have a link that shows how to compile a Qt app without moc? I looked
specifically for this and could only find this, which is unofficial and
contains a bunch of ugly macros: [https://woboq.com/blog/verdigris-qt-without-
moc.html](https://woboq.com/blog/verdigris-qt-without-moc.html)

~~~
carewolf
Just don't use slots.

------
steaminghacker
Ive been using QtQuick for a while now and the last two weeks i've battled
with 5.7RC. So, time to dl the proper release and see if it works any better.

My conclusions are that it's fantastic for desktop apps, but I'm having a lot
less success with mobile, specifically Android.

Originally, my plan was to reserve QT for desktop and write the mobile
versions separately, whilst sharing the same C++ backend. However, i got
tempted to try cross compiling my desktop version for Android.

After a massive battle, it works - a bit. But there's enough that doesn't work
that prevents me from making a release just yet (cut & paste is missing!).
Looks like I'll have to fill in the blanks myself.

Then Android is always a pig. I'm chewing over whether to recompile QT from
source and start hacking it about for Android. This is what Ive had to do with
pretty much all the cross platform systems. Android support is always poor and
buggy.

On LGPL, I'm fine with it. If you want my QML source code, sure. But for now,
I'll keep the backend DLL/.so closed (although I'd like to open that too, when
ready). If you want to be able to change the front end and rebuild, I'm ok
with that too. in fact, I'll happily document the backend interface for you.

Can we have more Controls.2 QML examples please (most are recycled v1
examples). QtQuick lacks in the tutorial department, although the online docs
are good, once you know what you're looking for.

qmake is great, but qtcreator sucks, sorry. Qt widgets is obsolete, QtQuick is
the way, once you get over QML.

~~~
volomike1
I agree that Qt widgets is obsolete with the market -- they're not keeping up
with the latest developments in interfaces and should just abandon this.

My question to you is why bother with QtQuick when you can build your
interface in Webkit/HTML/CSS/jQuery? With the Webkit angle, then you can
integrate file:// and remote content, and can utilize the best interfaces that
the web has to offer, which is innovating far faster than QtQuick could ever
dream of innovating because there are more web UI coders than there are
QtQuick coders. The other great thing with the Webkit approach is that you can
hire lower-cost UI coders (who have no background in C++) to do your
interface, and debug it using Chrome. The interface would show up in the upper
left-hand corner of the browser. They could stub it all out with fake data and
get it working completely, and then pass it to you to do the jQuery
connectivity to the Qt/C++ DOM injection so that jQuery could call C++ and get
results.

However, if installer size is a concern, then yes, QtQuick is the way to go.

~~~
steaminghacker
Good question. maybe i don't know the answer. I've been impressed by the way
that QML and C++ integrate. I write bits of UI glue JS in QML and these bits
call into C++ "magically". I can pass data in and get data back.

This is a lot easier than my JNI battles with Android Java.

I tend to have a lot of backend C++, which performs all the heavy lifting of
my apps. I like to make the front UI as thin as possible. QML lets me build
things quite fast and i like the way that properties update themselves.

The only real complaint i have with QtQuick/QML is things not working properly
on Android. But I'm hoping this situation will improve, and the main reason
I'm looking into Controls.2

You say that jquery can call to C++. Where can i find out about this and how
would this work on Android.

~~~
volomike1
> You say that jquery can call to C++. Where can I find out about this and how
> would this work on Android?

If you use Qt 4.8, which required that you use Qt Webkit, then you're looking
at needing to use the QtWebkit Bridge: [http://doc.qt.io/qt-4.8/qtwebkit-
bridge.html](http://doc.qt.io/qt-4.8/qtwebkit-bridge.html)

If you're using Qt 5.7, which also requires that you use Qt WebEngine, then
you're looking at needing to use QWebChannel:
[http://doc.qt.io/qt-5/qwebchannel.html](http://doc.qt.io/qt-5/qwebchannel.html)

They allow you to take a QObject class and then share it with the Webkit DOM
as a Javascript object. You can then use Javascript and jQuery to call class
methods (only ones you expose) of your Qt/C++ QObject class.

BTW, outside of Qt/C++, on the Mac with Objective C, they provide a way to map
the AppDelegate to the Webkit DOM using the windowScriptObject, and ObjC lets
you use the native Webkit SDK, rather than having to ship another one with
your project.

This is great for desktop applications. Unfortunately for iOS and Android,
however, both Qt 4.8's Qt Webkit and Qt 5.7's Qt WebEngine are not supported
on those mobile platforms.
[http://stackoverflow.com/a/30662323/105539](http://stackoverflow.com/a/30662323/105539)
I guess on those, you're stuck with using QtQuick/QML interacting with jQuery
and C++, I guess? EDIT: On Android and iOS, you can use Qt WebView within a
QML application, which uses the native Webkit on each OS.
[http://doc.qt.io/qt-5/qtwebview-index.html](http://doc.qt.io/qt-5/qtwebview-
index.html)

If I were to develop for iOS and Android, I'd probably use Apache Cordova
until something better comes along:
[https://en.wikipedia.org/wiki/Apache_Cordova#Supported_platf...](https://en.wikipedia.org/wiki/Apache_Cordova#Supported_platforms)
. One criticism is that Cordova may be slow in some actions, but phones are
getting much faster in every release, negating this trouble.

~~~
steaminghacker
thanks for this info. i'll checkout WebView, see what it can do.

------
volomike1
My understanding is that with Qt, you can keep your own Qt source compiled
(and not shared) and use the open source license of Qt, but must dynamically
link to the runtimes, list the open source license in your application
directory, and list a URL where people can download the source of those Qt
runtime DLLs that you are linking.

Also, I found the widgets sub-par to modern interfaces you see on the web
today. Let me give you a good example. Do you know those "Check All"
checkboxes at the top of grids to check all the checkboxes on the left column
of a grid? Yeah, to do that with Qt widgets requires subclassing and
intercepting paint events. To me, that's a kludge. So then there's QtQuick.
When I compared what I could do in QtQuick compared to what I could do with
Webkit/jQuery/CSS, I wondered why be hampered by the limitations of QtQuick
when I could just get it all in Webkit/jQuery/CSS. So, I opted to build my
stuff in Webkit/jQuery/CSS and use the C++/Webkit bridge that adds an object
to the DOM that I can interface with jQuery. The other advantage is that I can
hire a web designer (cheaper than a C++ coder (who, often have poor interface
skills, anyway)) who knows a bit about jQuery/CSS to design the interfaces for
me (they appear in the upper left corner of a web page). We make them web
server-less -- they load with file:// handles. Then, I still have the option
to IFRAME web content as well as use REST-like APIs (JSON or XML) via jQuery
to interact with the web server, or let the C++ interact with the web server
over REST-like APIs. The other great reason to use Webkit is because it has a
vast library of freely explained techniques for great interface widgets.

There was also a mention about charts. I use Chartjs.org inside my Webkit
interface.

The only drawback about going with this Webkit technique is that it does
increase the size of your project considerably. On Windows, there's no getting
around this. However, on the Mac, the way I got around it was to take my
Webkit interface and port it to Objective C/C++ (and try to keep most of it in
C++ because I find ObjC quite messy and bizarre, and because I can wrap ObjC
stuff in C++). I use a Webkit widget on a form, and it uses the native webkit
that comes with the Mac. Therefore, the installer download is tremendously
smaller. I then ported the Qt/C++ code into ObjC/C++ -- that wasn't easy, but
was manageable for any trained C++ coder.

~~~
defiancedigital
"C++ coder ... often have poor interface skills, anyway" ... troll inside

~~~
volomike1
I'm not trolling. Someone told me, "Hey, you're a C++ coder. You have like no
design skills. I've seen your stuff. It needs work." The investor then brought
in a UI expert and wowed me. It was then that I realized, "Wow, I don't have
good UI skills." I imagine this is probably the case with many C++ coders.
Sorry to offend if you're an awesome UI expert AND a C++ coder.

~~~
defiancedigital
So, if you "don't have good good UI skills" please stop your comments about
QtQuick ...

------
wampler
TODO: Hello World Exercise

#include <QCoreApplication>

int main(int argc, char *argv[]) { QCoreApplication app(argc, argv); return
app.exec(); }

------
Siecje
Anyone have a good Qt 5 book? Preferably one that uses QML and Python.

------
defiancedigital
Any comments about android service support ?

~~~
steaminghacker
Apparently Android services is now in 5.7. This is good news because i need
them. I've been working to supercede my Java app with QtQuick and replacing
the services was going to be a problem.

I havent tried the Qt services yet (plan for next week). I hope they work!

