How can I create a simple program such as a chess or checkers game (if it’s too difficult you can tell about something else)? The game should have a graphical interface, and it should be opened as a program, not in Jupyter Notebook or something like this. I didn’t find this information. Is it even possible in Julia?
although this is REPL-based. But it might be a start.
1 Like
As far as the UI goes, as far as I know the only working (non-web-based) UI kit in Julia right now is Gtk.jl, so you might want to check that out.
It would be great if we could also wrap a package like Qt or something, but unfortunately C++ interoperability is in a pretty bad state right now. Cxx.jl is abandoned (the author has been busy with his impressive work on the Julia compiler itself, so we all have him to thank for many of the exciting 1.0 features) and CxxWrap.jl is much more labor intensive, so to say that using it to wrap Qt would not be fun would be an understatement.
(Full disclosure: I don’t personally care much about UI’s. I like to think I care a lot about the C++ interoperability, but I haven’t found myself needing it so I’ve done exactly 0 work on it myself. So, you wouldn’t be wrong if you interpreted the above paragraph as just a shameless plug for C++ work 
.)
1 Like
There is QML that uses CxxWrap if you want to do it with Qt, but it’s still in the process of being ported to Julia 1.0 AFAIU
1 Like
As I see, all libraries presented above (not REPL-based) use code from C and C++. Do I understand right that GUI (not through Jupyter, etc) can be realized in Julia only in libraries written in other languages?
At present that is correct. Those libraries (e.g. Gtk, Qt) tend to be enormous efforts, and there are not many of them (as far as I know). They tend to be in C++, so for most languages it will be the case that UI’s use those. There is no fundamental reason why such a library couldn’t be written in pure Julia, but it hasn’t happened yet, as should not be surprising since Julia is so new. I suspect that we will have to have static compilation before such a pure Julia library is any good, so that may be one barrier.
It’s worth bearing in mind that Julia code can be very closely integrated with C code. It does not require any special packages, special syntax, special anything to call C code, and there is no overhead beyond that of calling a shared library, so Julia wrappers of C libraries tend to be quite good.
5 Likes
If you want something closer to the metal you can use OpenGL, SFML or SDL:
These things basically handle opening a window, drawing and inputs, then you do the rest in Julia.
1 Like
This is kind of off-topic here, on GUIs (and C++), but I answer for both here, as interesting (while there’s some other Discourse discussion thread covering GUI work):
First there are some alternative, non-GTK, and unrelated to Qt/QML/C++ solutions, using (“alpha” state, it least one package) C code, that have been wrapped by Julia, and meant for games.
For CxxWrap, while it gives me the impression of build failure, the main component builds for Julia 1.0, so possibly CxxWrap roks too on Julia 1.0 (or master) already; and thus also QML.jl:
https://ci.appveyor.com/project/barche/libcxxwrap-julia
QML least works/ed for pre-1.0/0.7 and you could use Julia 0.6 (or 0.7?) in the meantime. What was your problem with it over Cxx.jl (other than Julia 1.0 support)? Is it that Qt (as a whole) has much more classes than QML requires? Even if you only need the Qt classes required for GUI use (Qt has I believe many more classes), maybe the required ones aren’t too many to wrap?
Even if Cxx.jl isn’t working for Julia 1.0, it may already work for 0.7, the issue for compatibility with was merged. Yes, since that time CI only shows build failures, and Cxx seems to depend on LLVM, and there’s the problem for 1.0 compatibility. It seems we have to wait for Julia 1.1, but since that issue was solved, maybe Cxx.jl already works on master? And thus Qt, or all of it could work, not just QML?
–
Right, but not all e.g. LibUI (if I recall correct name) is in C and so is GTK. And when in C++, as with Qt, such is already wrapped by Python, and if Cxx and CxxWrap is a problem you could wrap the Python wrapper… and I understand it’s already done for Qt (and Tk). As GUIs are ofthen not speed-critical, e.g. for some games (while Chess is for the main Chess engine), you could derive from Python classes using PyCall (and those already subclass Qt).
Could someone explain how it’s possible? I saw Julia in Jupyter and in JuliaBox, and I simply don’t understand how it’s possible to go from code in them to GUI (without using C++). The code should open a window but I don’t understand how it’s possible the code in Julia opens a window. I understand that this is impossible now, but I want to understand the mechanism. My text is messy but I hope you understand what I mean (let me know if no)
Only that it seems like it would be extremely laborious to implement a wrapper with CxxWrap. In fact, I’m not even sure what the ideal procedure this this would be since one basically needs to write a wrapper on both sides of the language barrier: should one do the bulk of the wrapper in C++ or in Julia? Perhaps I’m making too much of it, but it hardly seems like the trivial drop-in that Cxx would have been.
I suppose but (especially considering that I have a significant amount of C++ experience), that sounds horrible to me.
Well, keep in mind, at some point those packages would ultimately have to make some kind of call to the display server, the graphics drivers, whatever, which would typically involve making a call to a (C) shared library or something. There are some existing Julia projects which compile Julia code directly to GPU kernels, see CUDAnative.jl.
1 Like
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.
I suppose in theory you could write inline assembly to make system calls and create a low-level graphics library in Julia, but why would you? I think this is a case where reinventing the wheel would be silly.
If any statement I’ve made here is not accurate, know that I don’t actually do any graphics programming myself; these are just my bird’s-eye impressions as a Linux user and scientific programmer.
4 Likes
Yeah, I guess what I was trying to say in my last post is that basically that’s what would wind up happening. Again, you can compile Julia code to run directly on other hardware, but even if you did that, you’re going to be making calls to the display server or whatever. 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.
3 Likes
I think we posted at about exactly the same time 
1 Like
I may misremember but I think JuliaBox (and Jupyther) is for web work, and if correct, that it’s run server-side (and at least if that server isn’t running locally as with JuliaBox), then it’s likely you can’t use any such GUI solutions (without X Windows).
This in independent of C++, but as I’ve already answered you need not use C++ at all (for Gtk.jl), or if directly:
Most use Qt (that’s written in C++) just from C++. But at least some from e.g. Python (or other wrapper). Are you saying that’s bad (or from other language with an official wrapper), or just just that a wrapper around a wrapper is bad? Just in this case or in general [for C++]?
On famous example is that TensorFlow.jl wraps Google’s official Python API. But that API, is also a wrapper (at least most of it), for C++, or may have been C. As I said, PyCall.jl is not just to call Python code, also sub-class, see the docs. It seems simple.
Maybe if someone says they’re going to make a Chess package with a GUI, people will feel the heat and make one this weekend?
1 Like
I’m saying that a wrapper around a wrapper is bad, particularly if the mediating language is Python, a scripting language which is itself designed for being the “outermost” wrapper. On the other hand if you wrap a C++ wrapper of a C package, you probably wouldn’t even notice it (in part because C is a subset of C++).
I don’t mean to disparage the TensorFlow.jl creators, it’s nice to have access to the functionality it offers, the wrapper is well written, and I have used it myself, but it’s sort of a worst case scenario. Granted, this package was started years ago when pure Julia deep learning packages seemed further off (as I recall Knet existed at the time but always had problems with language updates), so I’m sure a big part of the motivation was just to get some deep learning functionality easily accessible through Julia, a need which I shared at the time.
TensorFlow (itself, not TensorFlow.jl) is a strange tale. Of course, the important parts of TensorFlow are written in C++, but, initially at least, the authors seemed very insistent that the primary interface for it be through Python, and at the time the documentation of the C++ API was almost non-existant. I’m sure that the reason the authors of TensorFlow.jl chose to wrap the Python wrapper rather than the core C++ implementation was because of this lack of documentation, possibly combined with what may have been at the time a less-than-stellar state of the Julia C++ interoperability. Back then, I had only just gotten into Julia rather recently off the heels of around 8 years of C++ usage, so when I saw the docs for TensorFlow I did a fair amount of head scratching (as in: why not just use it in C++?).
Not sure what exactly you are refering to here but if you (or others) are referring to creating a julia GUI library that’s independent of the existing ones. Please don’t.
I’m not talking about reinventing the whell or wasted your own time here and I’m not talking about not being as well tested or cross-platform either. I’m talking about GUI library being a platform that must do MUCH more than drawing something on the screen. (This part is not trivial but that’s only your own business.)
A GUI library is responsible for taking user input and due to the non-CJK nature of most project out there, the input method support is always terrible for anything that’s not using standard widget in a standard library. This includes custom widget in standard libraries as well as custom libraries. This is one of the few technical area that I’m aware of where windows is doing much better than other platforms though it is not totally immuned.
Our community had enough trouble supporting (more like hacking) 2 major graphic libraries (Gtk and Qt) while still very frequently hitting bugs in anything that’s not using them so please don’t create anything new unless you understand all the need for the input side and not only the drawing side.
4 Likes
First as the GUI discussion (and at least C/C++ interop) is off-topic I point to:
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:
“PySide2 (part of Qt for Python) 5.11.2 Technical preview / 21 September”
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.
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).
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):
Depending on what you want
is an example that is in Python (not C/C++) directly. I mention it in case you want to target mobile (what it was made for). It even has support for Windows and Linux, while I think that’s newer and secondary.
To use this from Julia has not been tested as far as I know (no known wrapper), but you should be able to use any Python code from Julia, all-else-equal. Here it isn’t. Android support for Julia has been demoed, but seems immature, while Kivy may help. And iOS should work in theory, just not heard of done in practice.
I also took this example, as if it works or is made to, that it’s probably not calling C/C++, the wrapper is calling Java likely next, while at some point “C” (that is “bionic”) is involved.
1 Like