Chess game

[Palli]

First as the GUI discussion (and at least C/C++ interop) is off-topic I point to:

Julia for GUI app

Hello, I see there are GTK bindings for Julia language for those desiring to write desktop GUI app. However I’m evaluating whether Julia can replace Python as suitable language for writing GUI apps which has things like PyQt which is probably better option than GTK. There is Cxx project providing C++ interface, but I’m simply not aware of any Qt bindings for Julia? Another (potential) possibility it to use Julia for the ‘business logic’ and combine it with PyQt by using PyCall, but no idea ho…

I’m not sure it’s wanted to add to that thread (nor start a new one?). Since the GUI thread within this thread is more general than only a “Chess game” and people may be interested (at least if there’s new info here, e.g. relevant to Julia 1.0) I propose splitting it out (I just don’t know how to extract the discussion, and I believe I don’t have the permission).

A more closer to home example of wrapper on a wrapper may be, PyPlot.jl (that wraps matplotlib), and is at least graphical.

There’s no big problem with wrapper on wrapper, across languages (at least to C/C++), or within, e.g. Plots.jl to PyPlot.jl [to matplotlib].

While PyCall.jl README doc mentions PyQt you could use (may not be wanted because of GPL, and only for Qt4), it also mentiones the better option (at least to get LGPL) would be:

PySide

“PySide2 (part of Qt for Python) 5.11.2 Technical preview / 21 September”

@ExpandingMan

TensorFlow (itself, not TensorFlow.jl) is a strange tale.

Yes, Knet and/or Flux may be better for machine learning, but not because of wrapper issues. TensorFlow.jl even claims better API than the original Python one. But now we’re even more off-topic.

@ExpandingMan

So yes, basically I think you’re right, you have to work within the framework of existing operating systems, which are written in C, which is part of why it’s so nice that calling C is already a part of (core) Julia syntax and functionality.

I don’t think you want to work with the framework of e.g. Windows, as then you’re no longer portable (unless those, e.g. from C#, not the “C”/lowest-level APIs, are better).

@Sean_McBane

What everybody is glossing over here is that, in some sense, you can never write a graphical program without “using C/C++” in the sense that you want. Any time you do it in a high-level language, you’ll be calling a library, however low-level, that interfaces to the operating system to control the graphics hardware. And guess what? The OS interface is just the lowest-level C library of them all.

@rohqhq

There is no fundamental reason why such a library couldn’t be written in pure Julia

Could someone explain how it’s possible?

You could call the lowest level of the OS, for GUI, or non-GUI work. That’s bad for many reasons, and would tie you to Windows only. For GUIs (or non-GUI stuff), even if you accept being tied to Windows there are better APIs/frameworks than this (and despite the other side of the API written in C, it’s really just compiled machine code, and kind of wrong to say the interface is C, despite the ccall keyword used to call it):

Calling Win32 Functions From Julia