Qt GUI bindings

[alehander92]

(From Nim community survey 2017)

[mratsim]

Blas, lapack tracked in #77 and provided by nimblas, neo, arraymancer.

So tracking only the QT bindings part here

[treeform]

There is one here: https://github.com/filcuc/nimqml
Not sure how good it is.

[hippylover]

That's only for the qml bindings of qt.

[define-private-public]

While it's not quite Qt, there is CopperSpice: http://www.copperspice.com/

It's a fork of Qt 4.8 that had the goal of getting rid of the MoC. That thing was probably one of the main hindrances into developing a Nim binding. AFAIK, it is mostly API compatible (even with Qt 5), but there still are some notable differences.

[michael72]

Alternatively to the aforementioned Copperspice there is Verdigris which was inspired by Copperspice and claims to have better usable macros than Copperspice and directly works with QT up to 5.10 leaving out the moc.

Seems also it has much less compile time than Copperspice as described in this article.

[cornfeedhobo]

Literally every year I search this topic, waiting for this to happen. It's my top use case for switching to nim, and the only reason I consider learning another language. Most other backend services I can write in what ever language I already know and is convenient.

[Araq]

Most other backend services I can write in what ever language I already know and is convenient.

Well Nim is the most convenient language, so you can switch to Nim already. ;-)

[define-private-public]

I'm not used nimqml yet, but right now I might say that could be your best bet. This does limit you to well, only the Qml portion of the Qt library, not the traditional Desktop/QtWidgets part. As someone who has worked with both ways of building GUI apps using Qt, I would recommend you build any future GUI applications with Qml. Transitioning from Desktop/QtWidgets to Qml can be quite confusing at first, but later on things do start to make a lot more sense.

tl;dr: Use Qml with Nim.

[zocker-160]

I would recommend you build any future GUI applications with Qml.

@define-private-public out of curiosity: why exactly is this the case?

[define-private-public]

Qml is much more flexible compared to the traditional Desktop/Widgets API. As well as it should be hardware accelerated. You can also have much more control over how your app looks cross platform (including mobile & desktop). It's also much more touch friendly.

[kraptor]

Qml is much more flexible compared to the traditional Desktop/Widgets API. As well as it should be hardware accelerated. You can also have much more control over how your app looks cross platform (including mobile & desktop). It's also much more touch friendly.

This is true to some extent. For boring desktop business apps, using the traditional toolkits is a lot more convenient:

• Standard controls with native-look.
• Lots of convenient and useful controls already built.
• Docking, subwindows, toolbars with drag and drop, trees with native behaviour... there are hundreds of controls that replicating in Qml would be painful or will take ages to build correctly, when that effort was already done for the standard toolkit.
• Only one language: no need to mix and match with JS when there aren't things exposed to C++ (Nim would be the case, if proper bindings are ever done).
• Anything that needs accessibility/automation needs the traditional toolkit, there is little to no support using QML (same happens for Electron-based applications). You need to put LOTS of love to have something half-working in this area... but using the traditional widgets comes almost "for free".
• You don't need an accelerated (OpenGL ES) canvas but just native calls to 2D APIs are used (most of it IS hardware accelerated, btw): this is a lot faster on many cases when no fancy animations/transparencies/whatever are needed, and also a lot less resource hungry than a 3D canvas rendering at XX fps if you don't put effort to invalidate the canvas correctly.

I see both approaches as complementary, but denying the benefits of the traditional API is more than questionable.

Sure, if you want/need a flashy electron-like application with the current concept of "modern", go ahead with QML. When you need boring business apps there is a clear winner as of today.

EDIT: grammar, typos.

[jerous86]

Literally every year I search this topic, waiting for this to happen. It's my top use case for switching to nim, and the only reason I consider learning another language. Most other backend services I can write in what ever language I already know and is convenient.

This year is the year: nimqt :)