4 ms·
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 i
by scrollaway 10y ago
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.
- rsp1984 10y agoWe 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.
- steaminghacker 10y agoSame 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.
- ryandrake 10y agoQt'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.
- JBReefer 10y agoShouldn't you always have a layer between your business logic and display logic? Seems like this shouldn't be an issue with proper MVVM.
- electroly 10y agoSure, but you still have to write that display layer. You're just moving it around on your plate. You still have to eat it.
- api 10y agoThis 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.
- watmough 10y agoYeah, 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.
- gusmd 10y agoI'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.
- steaminghacker 10y ago+1. that's exactly what I do.
- ocdtrekkie 10y agoAs a note, Qt doesn't handle DPI well, it seems. Qt apps are almost unusable on a Surface Pro 4.
- scrollaway 10y agoOld versions of qt. Anything after 5.5 should be fine.
- ocdtrekkie 10y agoGood to know!
- steaminghacker 10y agoYes, HiDPI support was added. I need it for Windows 4k screens.
- rch 10y agoI've seen a significant uptick in Qt projects in the last 2-3 years.
- BlackMonday 10y agoDo you remember if this was with C++ or Python?
- rch 10y agoC++ in Boulder and Python in NYC.
- rer 10y ago> I know you haven't I used QT before. Please don't be presumptuous.
- ufo 10y agoMy 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.