Chess game

Why not just make it using WebIO? If you want to turn it into an app, it seems easy enough to port to electron?

Why overcomplicate things with qt and c++?

Also, this point seems a little unusual:

Why does it matter if it can be used in a Jupyter notebook? What’s wrong with js/html/css?

I’d start by trying the chess game with Makie. A 2D version should be pretty basic and I wouldn’t be surprised if a 3D version isn’t too hard. Makie can “plot” your game pieces quickly and respond to mouse events. If you need menus and widgets, that’s harder, but for the basic gameboard and movement, Makie should work well.

Of course the easiest way to make this happen is to put up a challenge to @sdanisch–Simon loves those!


AFAIU Makie is getting an experimental web-based backend, which means you could combine it with Interact to get extra widgets (dropdown, checkboxes, textboxes and what not). Of course this would not be a native solution, but as mentioned already you can always run it locally with electron.

Personally, I dont like the web interface or electron very much. It consumes more system resources and is unresponsive compared to a native app, like VIM. But I am very happy with the julia REPL interface, it is extremely powerful.

The fact that the jupyter notebook requires a web browser is off putting for me too. I like that Mathematica notebooks dont require a web browser. I dislike web browsers, they are bulky.

Would be fantastic if we could have jupyter notebook in a native program like Mathematica.

1 Like

jupyter qtconsole just got a re-vamp, so you could look into that. But it doesn’t have the a lot of the nice aesthetics and features that jupyterlab now has.

Another approach could be to compile a small front-end gui application in C/C++ specifically for chess/etc, and then call back to julia for the computations

1 Like

I am not an expert on this, but I expect you could communicate with an X11 client using just TCP for many things.

But just to get back to the original motivation of @rohqhq, which, if I understand correctly from another topic, is to learn programming and Julia: I think that starting both programming and Julia with GUI programming (of any kind) is not the best idea. While it is feasible, this is not where Julia shines.

Finally, both the other topic and this one focus on things that are not of primary relevance: protection from reverse engineering (I guess?) and writing everything in Julia only. These are distractions at best when one is learning programming.

1 Like

Here’s how you can draw a chess board in Gtk.jl (from the docs) :

using Gtk, Graphics
c = @GtkCanvas()
win = GtkWindow(c, "Canvas")

function rect!(ctx,x,y,w,h,col)
    rectangle(ctx, x, y, w, h)
    set_source_rgb(ctx, col...)

@guarded draw(c) do widget
    ctx = getgc(c)
    h,w = height(c), width(c)
    for (i,x) in enumerate(linspace(0,w,N)), (j,y) in enumerate(linspace(0,h,N))
        rect!(ctx,x,y,w/N,h/N, mod(i+j,2)==0 ? (0.1,0.1,0.1) : (1.0,1.0,1.0)  )

There’s also an example of handling mouse clicks in the docs.

Or with Makie:

using Makie
using Base.Iterators: repeated
r = 1:8
board = isodd.(r .+ r')
scene = Scene(resolution = (1000, 1000))
heatmap!(scene, board, scale_plot = false, show_axis = false)
# could be replaced with actual images!
white = ['♕', '♔', '♖', '♖', '♗', '♗', '♘', '♘', repeated('♙', 8)...]
wx_positions = [4, 5, 1, 8, 3, 6, 2, 7, (1:8)...]
wy_positions = [repeated(1, 8)..., repeated(2, 8)...]
w_positions = Point2.(wx_positions, wy_positions)
white_game = scatter!(
    scene, w_positions, marker = white, 
    scale_plot = false, show_axis = false, 
    markersize = 0.5, marker_offset = Vec2f0(-0.75)
black = Char.(Int.(white) .+ 6)
b_positions = Point2f0.(wx_positions, [repeated(8, 8)..., repeated(7, 8)...])
black_game = scatter!(
    scene, b_positions, marker = black, 
    scale_plot = false, show_axis = false, 
    markersize = 0.5, marker_offset = Vec2f0(-0.75)

function move_fig!(color, figure, target)
    game = color == :white ? white_game : black_game
    game[1][][figure] = target
    game[1][] = game[1][] # update signal
move_fig!(:white, 9, (1, 4))

To execute:


Thanks a lot, it’s exactly what I want to know.

Do you mean that code in pure Julia can’t potentially provide GUI or that Operating Systems are written in C/C++, so in some sense when the program is running, some parts of OS are included in work, so it means that GUI uses the code in C/C++ in some sense? By the way, it’s off-topic but is library provided by @ExpandingMan CUDAnative.jl written in pure Julia or it uses C/C++.? Is the library the first step to create libraries like Gtk written in pure Julia? I’ve checked the documentation quickly but I didn’t find out.

My main purpose is to know the limits of Julia, and this question is one of the ways to know it.

Yeah, I see. But again, it’s only a way to know the limits of Julia, I’m not going to use it for GUI. You say I just need to start, but let me give you an example. Let’s say one wants to learn a programming language, the person meets, for example, Pascal and then he or she tries to understand the limits of the language, and someone says him or her: “you don’t need to ask questions about the limits, you need just to start”, and the person learn the language for a long period of time and finds out the limits of the language in many many months. The person could use the time to learn something more useful. So is it a good advice not to check the limits of the language before learning? I think, no.

@jonathanBieler @sdanisch Thanks, I’ll check them.
And thanks to all. The community is really good

I don’t think it’s a useful mindset to focus on the edge cases and the absolute limits of a language when just starting out with programming in general. On one hand because most of the explanations and reasons for why some edge case or thing is hard to do in language X is really only relevant when already knowledgeable about that language and other languages, and on the other hand because if you’re only just starting out, you’re probably not going to hit those limits you’re asking for for quite some time anyway. That’s why the general tone here and in that other thread has been “don’t focus on what you can’t do or think you can’t do, here’s what you CAN do (easily)”.

With regards to your question about whether it’s possible to do EVERYTHING in Julia - I’m not quite sure you understand what that actually means. Doing everything in Julia would mean not using anything like Linux or Windows or Mac, not using any of the tools running on those platforms and on top of that not even running Julia itself, since that requires some foundation of those operating systems to even run at all (not to mention the stuff required to run the stuff Julia runs on…).

That said, nothing you’ve mentioned or we’ve proposed is impossible from a fundamental point of view, it’s just that a lot of it (like UI) is not really easy to do right now in Julia and requires a lot of additional work. That doesn’t mean that it’s not worth it to learn Julia though, because learning pretty much any language has its drawbacks and also specifics you can only learn while using that language. There just is no “perfect” first programming language out there.


Not really, i think the example was made, since most graphic calculations end up on the GPU and CUDAnative enables you to move pure Julia code to the GPU.
Does it use C/C++? Of course in some way - at least when it hits the GPU driver. Reimplementing the GPU driver is kind of impossible with all the vendor secrets and would also be pretty crazy, since it works just fine how it is.
In that sense, Makie is as close as it can get to a 100% Julia Graphics/GUI framework. It uses Julia up to the point where it sends the drawing calls to the GPUs OpenGL driver. I actually also made a prototype with a 100% Julia software renderer for Makie - which then is really 100% Julia … But would still need some way to display the Julia color buffer on the screen, which of course will need some C system calls.


My 2 cents, after researching a lot, experimenting a lot, I have to say that a native GUI in Julia today is not very feasible for a big program (maybe it is for a small chess board).

I am developing a space mission analysis software. All the computations are done in Julia using SatelliteToolbox.jl. The results are presented using a QML GUI. Hence, the C++ software calls the necessary Julia functions and show to the user.

This is not optimal, but very robust.

  1. The “limits” of a language are not well-defined. Most general programming languages are Turing-complete, so technically you can always do everything. It may just take more effort. This, in turn, is hard to quantify, so asking about it in very general terms will not give you very useful answers.

  2. A lot of the knowledge you gain when learning programming is transferable to other languages, especially if you are a beginner and you are just learning general concepts. Spending 3–6 months working with Julia will not be wasted effort, even if you end up using another programming language later on.


Although I agree generaly with you I have one small note:

This really depend on what one wants to code. GUI could be viewed as very basic limit for some people.

1 Like

Leave the GUI part. Just write the engine in Julia and use the Universal Chess Interface (UCI) for all GUI tasks. This is how most engines are written and there is no need to reinvent the wheel.