Hacker News Reader

Comment by deathtrader666 | Hacker News Reader

Wonder how the author didn't come across Qt or wxWidgets in his research?

I have the same question. There are many things that are problematic about Qt (personally, I loathe anything that feels the need to interject itself in the middle of the build process) but to completely ignore Qt without explanation - and subsequently post detailed experiences with libraries I've never even heard of - led me to believe the author exists in some uninteresting-to-me parallel plane of existence.

There was plenty of explanation for me when I first encountered this article (in the context of trying to solve the same problem):

> what cross-platform libraries are available for Nim!

Things might have changed over the past couple years, but, at least at the time, there weren't any (usable) Nim bindings for either.

Fair enough, but I think that the onus of proof is on the weird-language-user here. That is, a discussion of how cross-platform GUI toolkits are a 'trainwreck' takes on a different vibe if you're insisting on using Nim or Left-Handed Pure Phenomenological Haskell or the like.

I think you're maybe over-interpreting the article.

There is no (grammatical) article in its title. You seem to be assuming the article is implicitly "the", which would imply that it's intended for a more-or-less universal audience. It could just as easily be "a", which would then mean that it's more of a personal rant about the author's specific situation. I'd argue that the leading two sentences in the italicized portion of the article imply that it's the latter.

For the sake of throwing my own $0.02 in, I also have a historical habit of blithely ignoring wxWidgets and QT for my hobby projects. Their being written in C++ bit is a bit of a deal-breaker for me. The quagmire of interacting with C++ code from a language that isn't itself C++ in a cross-platform way results in me shaving my fill of yaks during working hours; I have little taste for doing even more of it during time that's supposed to be reserved for fun.

Yes, I guess so. I suppose I'm startled that someone would write such an elaborate article about such a remarkably specific situation without some intent to make a general statement, but whatever floats his boat I guess. You're definitely right that interacting with C++ outside of C++ (unlike the C ABI) is painful even before Qt's weird moc stuff gets going.

FWIW, I've made a very-early-alpha thing for making cross-platform apps with Nim: https://github.com/iffy/wiish

You mentioned it but, the strange meta object macro processing that qt depends up on, has been something I dislike. If I remember correctly GTK or other toolkits does not do anything similar.

And qt python bindings seems to be very poorly documented, same case with Java bindings.

The Java bindings for Qt are also horribly out of date. This has killled off my largest OSS project to date, just before it was starting to become decent.

The Qt Python bindings (PySide2 and PyQt5) do not need much documentation as they are just generated wrappers of Qt classes with the exact same API.

The first google hit for “qt nim” is [1] from 2017, so I think it’s safe to say it did not exist yet. The first hit for "wxwidgets nim" is [2], which has one open issue (since 2016): "Trouble building wxnim on win7".

Yes, time travel would solve most software development problems.

[1]: https://github.com/nim-lang/Nim/issues/6043 [2]: https://github.com/Araq/wxnim

He jokingly mentions Qt in the caption of the final picture.

I guess since he excludes GTK2 at the beginning for size concerns, wxWidgets and Qt would fall into the same category.

> He jokingly mentions Qt in the caption of the final picture.

well, he can keep joking and I can keep shipping Qt apps and everyone's happy

Except your users, they end up with your MBs.

I ship a Qt app. The installer is 135MB. 90MB of that is a demo video that comes with it. Nobody has ever complained.

yes, those poor users who end up with 70 megabytes to download, for something that comes with a large part of Qt, LLVM, libclang, multiple programming language implementation, support for plenty of network protocols... And I haven't even optimized what's inside the release package. ( https://github.com/OSSIA/score/releases)

Making a Qt app smaller would mean statically compiling the app and stripping the libraries but, hey, there’s an angry blog post that needs to get written.

Can you link us to your blog? I'd like to read that angry post if and/or when you post it.

I don't have an angry blog post about the size of cross-platform libraries.

Instead, I took the (longer) time to hand-tune Qt source and qconfig.h. My cross-platform desktop builds are under 2MB in a single executable, which appears to be something the OP wanted in the first place.

Oh, I think I misunderstood your original sentence. I thought you were saying there's an angry post that needs to be written about how to make a Qt app smaller by statically compiling the app and stripping the libraries. I was saying I would like to read the post detailing how.

But, now that I've thought about it for a few minutes, it does sound pretty straight forward. Unless Qt makes it difficult for some reason?

No, Qt doesn't make it difficult. We just live in a different era where it's more convenient to complain about frameworks than to dig in to the source/config files and modify them to suit your needs.

It's a Stack Overflow world, baby, we just live in it.

He does not like Qt because a simple window with a few buttons and sliders will end a big (in term of MB) application. He did not realize that one but another reason not to like Qt is that fact that they recreate the native look on each platform it's highly inefficient on macOS.

> another reason not to like Qt is that fact that they recreate the native look on each platform it's highly inefficient on macOS.

Given how everyone jumps on Electron these days, I don’t think thats a particular concern for anyone who just wants something to “simply be” cross-platform.

He complains that this creates enormous (in term of MB) application. My users sometimes have to rely on a lousy network connection to download. It can be because they are far away (China) or on a job. My users are in the event business and often have to rely on the WIFI of the hotel or the conference center.

It looks like Visix Galaxy is still alive and kicking, and it even supports UNIX, Windows, Windows NT, Macintosh, OpenVMS, and OS/2!

http://www.ambiencia.com/overviewgalaxytd.php

exactly, unless he really has something super special, QT should fix all his jokes. I don't use QT, but I think QT rarely has competition as far as cross-platform desktop GUI is concerned.

the only true "cross-platform" alternative is electron, which is a bit bloated and slow, but vscode is built on it, along with many others and worked fine. I personally prefer electron these days.

Qt and wxwidgets pretty much force you into using C++ and maybe python.

If you have to deal with all that baggage, then you might as well go build the UI layer native.

Huh?

https://wiki.qt.io/Language_Bindings

5.1 Qt for Python (PyQt)

5.2 Qt for Ring (RingQt)

5.3 Qt for Rust (Rust-Qt)

5.4 Qt Quick for Rust (qml-rust)

5.5 Qt Quick for Rust (qmlrs)

5.6 Qt for Crystal (qt5.cr)

5.7 Qt for Go (qt)

5.8 Qt for C#/Mono/.Net (QtSharp)

5.9 Qt for C#/Mono/.Net (Qml.Net)

5.10 Qt for D (QtE5)

5.11 Qt for Haskell (qtHaskell)

5.12 Qtah

5.13 Qt for Julia (QML.jl)

5.14 Qt Quick for Haskell (HsQML)

5.15 Qt Quick for OCaml (lablqml)

5.16 Qt Quick for Node.js (Brig)

5.17 QML bindings for Nelson language

Most of these are limited to the point of uselesness.

I ship nontrivial PyQt apps. PyQt can basically do anything Qt can do. Multiple inheritance of QWidgets can be dicey, but desired results can usually be achieved by defining mixins that don't subclass QWidget. It works brilliantly, far from "the point of uselessness". For me, cross platform GUIs are a solved problem, and I really can't wrap my head around all the noise to the contrary, or the claims that electron is what saved us.

Yeah that is why I said C++ and python...

Apologies, didn't see that

Python QT bindings are poorly documented, much of the documentation is out of date. Also it appears to me, far too much churn.

I don't use PyQt's documentation (wasn't even aware it really existed), it's such a literal wrapper that you can just use Qt's documentation.

And the only churn was a change about five years ago from a less pythonic API (using wrapped Qt types for most things) to a more pythonic one (using Python's native types where it makes sense). And that wasn't even that bad. Other than that it has no more churn than Qt itself does.

I use the D bindings to qt regularly when I'm not using dlangui for GUI.

The Common Lisp bindings (EQL) are solid as well.

I am the author of Qml.Net.

With it, you have the full power of .NET Core and QML. There really isn't any limits.

https://github.com/qmlnet/qmlnet

Quoting an article's (no doubt extensive) list of bindings for whatever library isn't a great way to start off a conversation about usable bindings in a given language. Bindings often exist, but they are not often any good.

What hyperbole! Writing a cross platform app in C++ using native UI libraries instead of something like Qt would be SO much more work!

Reply on news.ycombinator.com