Hacker News Reader

Comment by scrollaway | Hacker News Reader

Qt has a truly pleasant API and bindings in many languages. If you haven't used it before - and I know you haven't, otherwise you wouldn't be asking :) - give it a try. There's very little that's more cross-platform.

View on HN

Qt's nice, but the thing I've always disliked about it is that it re-implements all these basic types, like QString, QVector, QList, QMap, etc. and you need to use them to interact with all their APIs. So, you either have to decide you're all-in on Qt and have these QThis and QThat types littered all over your code (making it more difficult to interact with other third party libraries like boost that know nothing about Qt, or you need to agree on a boundary between your non-Qt-specific code and your UI, and maintain a layer that converts to and from standard types.

Shouldn't you always have a layer between your business logic and display logic? Seems like this shouldn't be an issue with proper MVVM.

Sure, but you still have to write that display layer. You're just moving it around on your plate. You still have to eat it.

This is common in older C++ projects that predate good quality STL and good compilers everywhere. They should factor it out, but that would break a ton of code.

Yeah, so sad, it just makes me think of all the code that could be cross-platform but for CString (MFC) and the like scattered through it.

I'm working on a Qt project, and our convention is to have a pure C++ back-end (i.e., STL), but use QObjects everywhere on the Models, Views and Controllers (as per Qt's MVC pattern). That way we can one day re-implement the UI if needed and keep the same "pure" C++ back-end. This has worked fine for us so far.

+1. that's exactly what I do.

We have chosen Qt for our new cross-platform app (Android, Windows, MacOS) which we've developed for the past 1.5 years and have overall not regretted it. Doing UIs with QML and Qt Quick is so much faster than Android's XML based system and gives you a lot of flexibility.

However there's a bit of a UI rendering overhead, although I understand they made it faster with Qt 5.7. And OpenGL integration is more complicated than doing it natively since you have to understand Qt's UI scene graph system and the way Qt is threading things.

But overall it's been a good choice so far.

Same here. I ran into a few problems with Android. Controls 2 is not quite ready yet, I had to write some Java, but it worked. Hopefully more AndroidExtras will be added in time.

I've seen a significant uptick in Qt projects in the last 2-3 years.

Do you remember if this was with C++ or Python?

C++ in Boulder and Python in NYC.

As a note, Qt doesn't handle DPI well, it seems. Qt apps are almost unusable on a Surface Pro 4.

Old versions of qt. Anything after 5.5 should be fine.

Good to know!

Yes, HiDPI support was added. I need it for Windows 4k screens.

My impression with Qt is that it has less language bindings than the alternatives. For Qt5 you find lots of bindings for QtQuick stuff but if you want to use traditional QtWidgets then its basically C++ or Python.

> I know you haven't

I used QT before. Please don't be presumptuous.

Reply on news.ycombinator.com