4 ms·

Awesome marketing video for an under hyped product! My startup abandoned .NET in favor of Qt to develop a cross platform screenshot app to digitize math equati

Awesome marketing video for an under hyped product! My startup abandoned .NET in favor of Qt to develop a cross platform screenshot app to digitize math equations because we wanted Linux support (https://mathpix.com https://mathpix.com) and it's delivered. We still use Swift for our Mac app. The thing about .NET is that it's not nearly as seamless as a development stack as Swift + the whole Mac ecosystem. Whatever clunkiness exists in Qt apps already exists 10x in the Windows ecosystem of clunkiness everywhere, because Windows itself is, in a sense, cross platform. So the difference between a Qt app a .NET app is not super noticeable on Windows. A good Qt app will be very nearly as good as a good .NET app, and a good Swift app on MacOS beats them all by a landslide.

CamperBob2 8y ago
and a good Swift app on MacOS beats them all by a landslide. In what sense(s) does the final application end up better?
- oppositelock 8y ago
  I ported a popular Google application from Windows to OS X using Qt Designer (and Qt in general) a number of years ago. Qt is really good for quick bringup of a cross platform app, and Designer and its associated code generator does a good job of generating reasonable UI's. Swift didn't exist at the time, but the combination of InterfaceBuilder and Cocoa was amazing. Where things start to get tricky is that Qt has to reimplement a lot of widgets themselves, on account of their target platforms being quite different from each other, so you end up with a slightly non-native feel on each platform, and some behaviors are subtly different. Things have gotten better since then, but that non-native behavior is still there. These behavioral differences aren't too bad on Windows and X11, since those platforms have a lot of inconsistency between apps, but mac users expect the mac to "feel" a certain way, and Qt is a little different, so we got a _lot_ of feedback, some of which I still remember - "Google Earth looks like it fell out of the ugly tree and hit every branch on the way down". The tradeoff you have with a cross platform toolkit like Qt is quick bringup of a cross platform app, versus later chasing down a lot of platform differences causing problems, and that slight non-nativeness. The alternative is to write your UI natively on each platform and abstract away the functional core from the UI, which is a lot more work but works better. If I was building a UI for major public consumption today, I would go with the extra work of native UI. If I was building tooling for my own developers, hands down, I'd use Qt.
Yuioup 8y ago
.NET = compiler and runtime (JIT). QT = UI library. What did you write your back-end code with? C++ ? (You mentioned that the Mac version is written in Swift, but what about the Windows and Linux versions)?
- oppositelock 8y ago
  Qt is more than a UI library, it abstracts away the platform too, from networking, to disk access, to UI. Think of it as an analogue to Chromium more than just UI.
  - figgis 8y ago
    It can abstract away from the platform. You can use it as a simple gui library just fine. I've been using it in place of Tk for my python stuff for a while now. (Qt.py is a lifesaver) I haven't even tried their options for what I want to do yet, but it is definitely tempting. Here's a good list of things Qt has stuff for. https://doc.qt.io/qt-5/modules-cpp.html https://doc.qt.io/qt-5/modules-cpp.html
- de_watcher 8y ago
  > QT = UI library. Oh no! Why then Qt is all over my server code?!
  - Yuioup 8y ago
    Seriously I thought QT was just a UI library. I stand corrected.
  - passerby2018 8y ago
    Incompetence?
- geezerjay 8y ago
  > QT = UI library. Where do you fit Qt's support for networking, SQL databases, standard directory structures, multithreading, etc... ?
IloveHN84 8y ago
You are comparing potatoes with tomatoes. Swift is developed by Apple for Apple ecosystem. Thus, the native calls are of course efficient. Qt is a framework that works as bridge between the native calls and your application, the same applies for .NET. If you develop on windows with WPF/MFC/Win32 calls, it will be obviously faster than Qt, because you're saving on that bridge calls. Why don't you use Qt on Mac then? The main advantage of using such a framework is that you have only one codebase/language that runs everywhere.
- MaxBarraclough 8y ago
  You've contradicted yourself. WPF is a .Net technology. Are you saying it pays a performance penalty, or not? > If you develop on windows with WPF/MFC/Win32 calls, it will be obviously faster than Qt, because you're saving on that bridge calls. Not so. Both frameworks make calls down into one of Windows' graphics subsystems. This is how all GUI toolkits work. If draw performance is important to you, Qt might well beat WPF, as it has a Direct3D 12 backend [0]. To my knowledge, WPF does not - as far as I can tell it uses Direct3D 9. Of course, none of this gives us any hard assurances that the performance of one beats the other, but in terms of the inefficiencies of using intermediate layers, it's far from clear than WPF wins. (I couldn't find any decent concrete numbers on this. I presume that's because GUI draw performance isn't a real problem these days.) I'm not convinced that Swift is any different (though it well might be a good deal less bloated). It seems unlikely that the syscalls end up all that different simply because of using a different language for your GUI work. > Why don't you use Qt on Mac then? Obviously I can't speak for nicodjimenez, but I presume it's because Qt doesn't deliver quite the native Mac feel that they're aiming for. My understanding is that Qt is also a little immature on mobile platforms, but I'm not sure that's relevant here. [0] https://doc.qt.io/qt-5.11/qtquick-visualcanvas-adaptations-d3d12.html https://doc.qt.io/qt-5.11/qtquick-visualcanvas-adaptations-d...
  - pjmlp 8y ago
    WPF makes heavy use of DirectX, .NET JIT can remove marshaling code on P/Invoke and COM calls and there is also NGEN for AOT compilation. .NET Core 3.0 will apparently finally bring .NET Native to Windows desktop apps as well.
tebura 8y ago
Testimonials on ur site mathpix are awesome. too geeky !!!

CamperBob2 8y ago

and a good Swift app on MacOS beats them all by a landslide. In what sense(s) does the final application end up better?

oppositelock 8y ago
I ported a popular Google application from Windows to OS X using Qt Designer (and Qt in general) a number of years ago. Qt is really good for quick bringup of a cross platform app, and Designer and its associated code generator does a good job of generating reasonable UI's. Swift didn't exist at the time, but the combination of InterfaceBuilder and Cocoa was amazing. Where things start to get tricky is that Qt has to reimplement a lot of widgets themselves, on account of their target platforms being quite different from each other, so you end up with a slightly non-native feel on each platform, and some behaviors are subtly different. Things have gotten better since then, but that non-native behavior is still there. These behavioral differences aren't too bad on Windows and X11, since those platforms have a lot of inconsistency between apps, but mac users expect the mac to "feel" a certain way, and Qt is a little different, so we got a _lot_ of feedback, some of which I still remember - "Google Earth looks like it fell out of the ugly tree and hit every branch on the way down". The tradeoff you have with a cross platform toolkit like Qt is quick bringup of a cross platform app, versus later chasing down a lot of platform differences causing problems, and that slight non-nativeness. The alternative is to write your UI natively on each platform and abstract away the functional core from the UI, which is a lot more work but works better. If I was building a UI for major public consumption today, I would go with the extra work of native UI. If I was building tooling for my own developers, hands down, I'd use Qt.

Yuioup 8y ago

.NET = compiler and runtime (JIT). QT = UI library. What did you write your back-end code with? C++ ? (You mentioned that the Mac version is written in Swift, but what about the Windows and Linux versions)?

oppositelock 8y ago
Qt is more than a UI library, it abstracts away the platform too, from networking, to disk access, to UI. Think of it as an analogue to Chromium more than just UI.
- figgis 8y ago
  It can abstract away from the platform. You can use it as a simple gui library just fine. I've been using it in place of Tk for my python stuff for a while now. (Qt.py is a lifesaver) I haven't even tried their options for what I want to do yet, but it is definitely tempting. Here's a good list of things Qt has stuff for. https://doc.qt.io/qt-5/modules-cpp.html https://doc.qt.io/qt-5/modules-cpp.html
de_watcher 8y ago
> QT = UI library. Oh no! Why then Qt is all over my server code?!
- Yuioup 8y ago
  Seriously I thought QT was just a UI library. I stand corrected.
- passerby2018 8y ago
  Incompetence?
geezerjay 8y ago
> QT = UI library. Where do you fit Qt's support for networking, SQL databases, standard directory structures, multithreading, etc... ?

IloveHN84 8y ago

You are comparing potatoes with tomatoes. Swift is developed by Apple for Apple ecosystem. Thus, the native calls are of course efficient. Qt is a framework that works as bridge between the native calls and your application, the same applies for .NET. If you develop on windows with WPF/MFC/Win32 calls, it will be obviously faster than Qt, because you're saving on that bridge calls. Why don't you use Qt on Mac then? The main advantage of using such a framework is that you have only one codebase/language that runs everywhere.

MaxBarraclough 8y ago
You've contradicted yourself. WPF is a .Net technology. Are you saying it pays a performance penalty, or not? > If you develop on windows with WPF/MFC/Win32 calls, it will be obviously faster than Qt, because you're saving on that bridge calls. Not so. Both frameworks make calls down into one of Windows' graphics subsystems. This is how all GUI toolkits work. If draw performance is important to you, Qt might well beat WPF, as it has a Direct3D 12 backend [0]. To my knowledge, WPF does not - as far as I can tell it uses Direct3D 9. Of course, none of this gives us any hard assurances that the performance of one beats the other, but in terms of the inefficiencies of using intermediate layers, it's far from clear than WPF wins. (I couldn't find any decent concrete numbers on this. I presume that's because GUI draw performance isn't a real problem these days.) I'm not convinced that Swift is any different (though it well might be a good deal less bloated). It seems unlikely that the syscalls end up all that different simply because of using a different language for your GUI work. > Why don't you use Qt on Mac then? Obviously I can't speak for nicodjimenez, but I presume it's because Qt doesn't deliver quite the native Mac feel that they're aiming for. My understanding is that Qt is also a little immature on mobile platforms, but I'm not sure that's relevant here. [0] https://doc.qt.io/qt-5.11/qtquick-visualcanvas-adaptations-d3d12.html https://doc.qt.io/qt-5.11/qtquick-visualcanvas-adaptations-d...
- pjmlp 8y ago
  WPF makes heavy use of DirectX, .NET JIT can remove marshaling code on P/Invoke and COM calls and there is also NGEN for AOT compilation. .NET Core 3.0 will apparently finally bring .NET Native to Windows desktop apps as well.

tebura 8y ago

Testimonials on ur site mathpix are awesome. too geeky !!!