Here's a nice project that we (Status) recently released in beta - thought it might be interesting to people that are into GUI applications and Nim:
https://github.com/status-im/status-desktop
Desktop is a private messenger (nope, no phone number needed) that eventually will also serve as a peer-to-peer node in the Status network (courtesy of nimbus), allowing people to run their own infrastructure for communication and transacting if they want to.
Briefly looking at the tech stack, it combines:
As always, the source code is liberally licensed for all to do with as they please ;) Happy to answer any questions as well.
Btw i'm very close to push QObject::connect in NimQml for connecting signals between QObject in Nim or C++/Qml and Nim lambdas.
One thing I've found tedious is to turn Nim objects into QObject to begin with - ie first creating a nim object with fields, then creating getters, setters and signals, then creating the QtProperty binding to the getter, setter and signal - would be nice if the macro could do something smart about this, for example with a "standard" field annotation - most of the time, I just want either a simple read slot or a read/write/notify that does the obvious thing.
Is there a more convenient way to do things? Here's a canonical example: https://github.com/status-im/nimbus-eth2/blob/3ebce8e683504d4b1f0433d1c578100bf37e1a67/ngui/nodemodel.nim#L47
I dare say that for an app that was started less than a year ago, by developers who were completely new to Nim that's an achievement.
See the debate on what stack to use back in May 2020: https://discuss.status.im/t/desktop-paths-forward-a-choose-your-own-adventure/1666
Guys my comment was not about you doing a bad job just about my experience with the app that I just tried out. I dont know from a technical perspective what makes it not as good as more "native" software. It's just huge to install and consumes just as much memory as an electron app. And clicking around feels more or less the same.
It could be the QML/QTQuick combo that's not as good as making the UI directly from code who knows.
Ah that's more clear what you meant.
I expect optimizations will be scheduled in the future but we need features and proper user experience first.
I expected the lack of "snapiness" perceived is because something is blocking the UI thread from time to time. Though here that requires fiddling with QT as I think it takes over the UI thread.