4 ms·

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 midd

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.

bunderbunder 8y ago
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.
- iffycan 8y ago
  FWIW, I've made a very-early-alpha thing for making cross-platform apps with Nim: https://github.com/iffy/wiish https://github.com/iffy/wiish
- glangdale 8y ago
  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.
  - bunderbunder 8y ago
    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.
    - glangdale 8y ago
      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.
billfruit 8y ago
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.
- gmueckl 8y ago
  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.
- Vogtinator 8y ago
  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.

bunderbunder 8y ago

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.

iffycan 8y ago
FWIW, I've made a very-early-alpha thing for making cross-platform apps with Nim: https://github.com/iffy/wiish https://github.com/iffy/wiish
glangdale 8y ago
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.
- bunderbunder 8y ago
  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.
  - glangdale 8y ago
    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.

billfruit 8y ago

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.

gmueckl 8y ago
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.
Vogtinator 8y ago
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.