
GoQt - T-A
https://github.com/visualfc/goqt
======
zanny
Qt has evolved fantastically since Digia's acquisition. Just throughout the
5.0 series it has gained incredible feature support for almost anything from
full multimedia faculties to websockets to a revitalized 3d rendering engine.
And QML is such a breakout success in UI design and just general applications
programming compared to the competition - if you have not, you must try coming
up with a simple program idea and then try implementing it in QML. Compared to
any other tech - GTK, HTML, even Android's ADT the mechanism behind QML is
incredibly elegant.

I dream of seeing a day in ten years or so where everyone _expects_ right once
run everywhere native look and feel applications out of Qt, a toolkit that
provides you mechanism to access the full power of your target devices without
having to lock yourself into whatever vendors SDK is and thus forcing you to
rewrite the same program 5 times for 5 different target devices.

Its not there yet - just the other week I was arguing with someone on reddit
about the usability of Qt on mobile and conceded it lacks a prebaked gesture
support library to easily just do a two finger swipe rather than having to use
the multitoucharea type to specify how two finger motion works - but it is
getting so very close.

~~~
tenfingers
I wished Qt just split into a different widget set for mobile. The interaction
behavior is significantly different that attempting to reuse the same UI for
both mobile and desktop will result in a terrible experience on both.

Likewise, QML is just plainly useless on the desktop, and _much_ slower to
booth. Unfortunately, the performance regression in Qt5 is there also if you
don't use it, and that shouldn't be.

Qt5 being slower than Qt4 is the main reason I've been moving slowly towards
copperspice ([http://www.copperspice.com/](http://www.copperspice.com/)) for
newer projects. The fact that moc is no longer necessary removes also the main
paint point of qt.

~~~
slavik81
I found QML items to be very useful on the desktop. Unlike the old widgets,
they can easily be overlayed over an OpenGL scene. That makes them a great
choice for a whole swath of software.

~~~
zanny
I'm definitely intending to try writing a Doom clone when 5.7 comes out -
thats when the QML Compiler is open sourced, and thats the first iteration
after Qt3D is API stable, so it should be fun to work with.

I'm just curious of how much force multiplier you can get writing the menus
with QML and the game with Qt3d.

------
u14408885
Whenever I hear of a golang binding to a library implemented in C++ I'm always
interested to see how they map the class hierarchy to golang's type model
which doesn't have traditional inheritence.

Does QT's class hierarchy map cleanly to Go? Is it just interfaces everywhere?

(I'm not trying to start a language war, just genuinely curious.)

~~~
rhodysurf
So it uses interfaces and anonymous fields. So if you are familiar with Qt,
something like QPushButton would be implemented in go by having an anonymous
field for QAbstractButton which would have an anonymous field for QWidget.
Furthermore, this class has to implement an interface so it can be passed
around like a normal QWidget in C++ would.

That was kind of a ramble, but thats the gist of it.

------
shmerl
How does it manage C++ bindings? Rust struggled with that, and it has a lot of
issues because of compiler specific name decorations and etc.

[https://en.wikipedia.org/wiki/Name_mangling#How_different_co...](https://en.wikipedia.org/wiki/Name_mangling#How_different_compilers_mangle_the_same_functions)

~~~
archimedespi
Rust has #[no_mangle] and ffi types. I've done some FFI in Rust, and I've
found it to be pretty pleasant. What are the "lot of issues" you're talking
about?

~~~
shmerl
C++ names decoration is a problem. no_mangle refers to Rust (i.e. it's useful
for calling Rust code from other languages). Rust has no control over C++
names mangling.

~~~
archimedespi
Okay, sorry, read your original comment backwards.

Calling into C++ is generally a big problem in any programming language
though, and for most, you have to write a C wrapper.

~~~
Lofkin
Not a problem for Julia:
[https://github.com/Keno/Cxx.jl](https://github.com/Keno/Cxx.jl)

~~~
reubenmorais
Looks like that uses Clang/LLVM. Does it work with C++ libraries built with
GCC or MSVC?

~~~
ihnorton
MSVC: probably not; Clang's MSVC ABI support is coming along well, but last
time I checked there was no COFF support in the JIT. GCC on Itanium ABI
platforms should be fine, although mixing C++ stdlib versions would be risky
(primarily an issue on OS X).

------
VeilEm
There's also [https://github.com/go-qml/qml](https://github.com/go-qml/qml)

~~~
brunoqc
Last commit is from a year ago.

------
l1n
So does this mean you could write a QT application in Go on Linux and cross
compile the whole mess for Windows?

~~~
archimedespi
I mean, theoretically, yes, if you're masochistic, but why wouldn't you just
compile on Windows? This set of bindings even supports Windows:
[https://github.com/visualfc/goqt#system](https://github.com/visualfc/goqt#system)

~~~
l1n
Mostly because I don't have access to a copy of Windows to compile on :)

~~~
archimedespi
Totally understand that :)

Maybe [https://www.appveyor.com/](https://www.appveyor.com/) would work out
for you? It's free for OSS projects.

------
josephcooney
I like LiteIDE, I will have to give this a shake.

~~~
nickbauman
Yeah someday maybe we can get a vertical split pane like other environments
have had for a decade or more!

~~~
aikah
A good thing liteIDE is free and opensource then, the one guy maintaining it
is waiting for your invaluable contribution.

------
api
Awesome, but them are going to be some fat static binaries. Of course I get
the sense that shared libraries are being abandoned so that seems to be how
things are going. You have to ship qt with any qt app anyway.

~~~
SwellJoe
It's unfortunate on Linux, but on Windows and Mac, as you note, you're already
shipping your users a copy of Qt with the application.

And, in the modern world of big computers (desktops and laptops), it is not
all that big of a deal (I don't actually know, but I would guess it's on the
order of a few MB, maybe in the tens of MBs), and from what I can tell a lot
of applications are already built statically for distribution to Windows and
Mac OS X.

~~~
api
I personally think it's a complexity management problem and a version
management problem. Shared libraries make sense for "timeless" stuff like math
or very core system stuff, but beyond that there is too much variation both in
version and in approach. Unless your target is a platform as rigidly managed
as Apple, you must ship it all or you will get missing shared library errors.

I do think changes in how shared libraries are shipped or managed may help.
I've had ideas for ages around using cryptographic hashes but have no time to
experiment with such things.

~~~
bitwize
Thw thing about Apple is they give no fucks about backwards compatibility for
developers anyway. You're a developer and you're working with Apple tech, so
naturally you were waiting in line in the cold to get their latest hw and sw,
weren't you?

This bit me on the ass when Apple forced a libstdc++ update on OS X 10.3 with
a new ABI, permanently breaking all C++ compilation on my Mac. Compiling C++
programs for 10.3 was still possible, but you needed a 10.4 machine, the
latest Xcode, and compatibility libraries to do it.

~~~
forgettableuser
That wasn't just Apple. The reason that happened was because gcc went from 3
to 4 in that time frame. gcc and C++ never guaranteed binary compatibility,
especially between major versions.

I had similar problems on Linux and Solaris because of that transition. My own
fault (actually my employer's) for assuming binary compatibility when it was
never promised.

~~~
gpderetta
GCC transition from 3 to 4 didn't break the ABI. The last required ABI break
was 3.0 to 3.1.

~~~
forgettableuser
I'm not being pedantic. libstdc++ was mentioned. That always can break.

The ABI between g++ transitions is also platform and architecture dependent.
Mac was PowerPC back then. Sun used Sparc. Not everything is always x86, even
on Linux.

~~~
gpderetta
You are right, I had forgot that GCC broke the libstdc++ ABI between 3.3 and
3.4 (not 3.x to 4.x though). That was 12 years ago, though, the ABI has been
stable ever since [1].

I still would characterize it a fairly stable ABI, not something that "can
always break", especially compared with other vendors that break the library
ABI every release.

[1] A new libstdc++ C++11 ABI was added in GCC 5.x but it is optional even in
C++11 mode.

------
elcapitan
QMessageBoxWarningWithParentTitleTextButtonsStandardbutton

And people make fun about
Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch in Wales.

------
rhodysurf
Whoa cool. I was working on a fork of his original goui library and updating
it for Qt5. Awesome to see this and im pumped to not have to keep working on
the other fork.

------
ozzmotik
my phone is showing there being a lot of empty comments from five decades ago.
clearly signs consistent with time travel.

------
malkia
While Qt is awesome, I'm not so sure about it's recent license change. I know
lots of people would love that, but for other programmers (stuck in big
companies) this simply means that they can't use it, as not always money would
be approved for commercial projects, even if the project do have a big budget.

~~~
SwellJoe
I don't understand this comment. Isn't it still under LGPL or more liberal
licenses, depending on the component, as it has always been? According to the
website, it is.

[http://doc.qt.io/qt-5/licensing.html](http://doc.qt.io/qt-5/licensing.html)

I see nothing in that list that seems different or that would prevent one from
building commercial products on Qt without licensing fees.

~~~
forgettableuser
LGPL v3 is _really_ complicated. That's a red flag for a lot of corporate
lawyers.

As a result, some issues arise, such as code that is stuck on GPLv2 (e.g.
removed the upgrade clause like the Linux kernel) may be incompatible with
LGPLv3.

This blog tries to explain some of the issues.
[http://nmav.gnutls.org/2013/03/the-perils-of-
lgplv3.html](http://nmav.gnutls.org/2013/03/the-perils-of-lgplv3.html)

~~~
belorn
I strongly disagree, since at a conceptual level it is a very simple license.
As a distributor, you got provide users with the source code of the LGPLv3
parts and _permit /provide_ so they can replace it with a modified version of
their choice.

To make a car analogy, if the tires are made under LGPLv3, you got to tell
them what kind of rubber it is made of and permit car owners to change the
tire without the car saying "unapproved parts used, so I will refuse to start
now until you have bought approved tires from an official car dealer". Every
car made before 2000 managed to do this without even thinking about it.

FSF consider GPLv2 to be incompatible with this deal from a US-legal view,
which is the same view that claim "further restrictions" only covers
restrictions made from software licenses.

