2 ms·

Most of your points revolve around QObject's having its own ownership and lifetime model, of course it will be extremely painful to work against that. No surpri

Most of your points revolve around QObject's having its own ownership and lifetime model, of course it will be extremely painful to work against that. No surprise there. QObject ownership is sound and quite practical though, as long as you're not actively trying to work against it. It's certainly not complicated. > Also arguably is because Qt brings along a lot of unnecessary baggage. You mentioned using Qt requires using qmake (which definitely counts as arcane, if not archaic); cmake does a pretty good job of wrapping qmake but doesn't eliminate it. CMake does not invoke qmake for Qt projects. It does invoke moc though. Perhaps you meant that you need to use moc? That's mostly true, though verdigris does work and only requires a modern C++ compiler. > And all of that is because of Qt's non-standard magical signals & slots system which is really just a more error-prone semi-async system when compared to any other eventing system. Signal-slot is simply a convenient way to declare events (signals) and connect callbacks (slots) to them, using implicit per-thread event queues. Pretty standard stuff. > Modern Qt developers also have to become javascript developers since Qt's UI is heavily driving towards QML. This is simply false. Qt contains two separate UI systems for two very different use cases. Qt Widgets does not use QML (or JS) and is your classic CPU-rendered desktop toolkit. Qt Quick is a declarative UI framework designed for layer-based GPU compositing, mainly aimed at mobile, embedded and "graphically rich" interfaces. You can write Qt applications for years and years and not even know how JS is spelled. > For GUI, Dear Imgui [0]. Imgui is a nice library, but it lacks a very large number of features you'd want in a desktop application, all of which you'd have to write yourself. Some of which you'll have a hard time developing (e.g. accessibility). This is of course because Imgui isn't meant to be a general-purpose GUI library for desktop applications. > For files, plain standard streams. It's kinda funny that you complain so much and then recommend iostreams of all things.

inetknght 5y ago
> CMake does not invoke qmake for Qt projects. It does invoke moc though. Perhaps you meant that you need to use moc? Indeed > Signal-slot is simply a convenient way to declare events (signals) and connect callbacks (slots) to them, using implicit per-thread event queues. Pretty standard stuff. They're not convenient because they're not standard and require ~~qmake~~moc. A regular function with a regular event loop is convenient. But Qt doesn't let you poke around its event loop without using signals and slots. > Imgui is a nice library, but it lacks a very large number of features you'd want in a desktop application, all of which you'd have to write yourself. Maybe in a full desktop application but remember the idea is for a small one. > Some of which you'll have a hard time developing (e.g. accessibility). A small free application doesn't need accessibility to be useful to the author. > This is of course because Imgui isn't meant to be a general-purpose GUI library for desktop applications.* If you say so. > It's kinda funny that you complain so much and then recommend iostreams of all things. iostreams are just as easy as qt and without the bloat needed for it.
- formerly_proven 5y ago
  > They're not convenient because they're not standard and require ~~qmake~~moc. A regular function with a regular event loop is convenient. But Qt doesn't let you poke around its event loop without using signals and slots. Like I said, you don't have to use moc, there are alternatives. Also, Qt has supported "regular functions" for many years, since you can use connect() with function pointers, PTMFs, lambdas etc. The only difference between a "regular function" and a slot: method is that the latter has some extra RTTI data which allows it to be safely called from dynamic bindings. Another use-case is old-style (Qt 4) connect where you pass the slot name as a string and connect() has to look-up the method pointer at runtime (and also checks parameter types etc.). That's a rare sight, though. > iostreams are just as easy as qt and without the bloat needed for it. iostreams is an atrocious API and bloaty on top. Easily the worst library in the C++ standard (in no small part due to its sheer age, being one of the oldest parts of the language).

inetknght 5y ago

> CMake does not invoke qmake for Qt projects. It does invoke moc though. Perhaps you meant that you need to use moc? Indeed > Signal-slot is simply a convenient way to declare events (signals) and connect callbacks (slots) to them, using implicit per-thread event queues. Pretty standard stuff. They're not convenient because they're not standard and require ~~qmake~~moc. A regular function with a regular event loop is convenient. But Qt doesn't let you poke around its event loop without using signals and slots. > Imgui is a nice library, but it lacks a very large number of features you'd want in a desktop application, all of which you'd have to write yourself. Maybe in a full desktop application but remember the idea is for a small one. > Some of which you'll have a hard time developing (e.g. accessibility). A small free application doesn't need accessibility to be useful to the author. > This is of course because Imgui isn't meant to be a general-purpose GUI library for desktop applications.* If you say so. > It's kinda funny that you complain so much and then recommend iostreams of all things. iostreams are just as easy as qt and without the bloat needed for it.

formerly_proven 5y ago
> They're not convenient because they're not standard and require ~~qmake~~moc. A regular function with a regular event loop is convenient. But Qt doesn't let you poke around its event loop without using signals and slots. Like I said, you don't have to use moc, there are alternatives. Also, Qt has supported "regular functions" for many years, since you can use connect() with function pointers, PTMFs, lambdas etc. The only difference between a "regular function" and a slot: method is that the latter has some extra RTTI data which allows it to be safely called from dynamic bindings. Another use-case is old-style (Qt 4) connect where you pass the slot name as a string and connect() has to look-up the method pointer at runtime (and also checks parameter types etc.). That's a rare sight, though. > iostreams are just as easy as qt and without the bloat needed for it. iostreams is an atrocious API and bloaty on top. Easily the worst library in the C++ standard (in no small part due to its sheer age, being one of the oldest parts of the language).