I think we posted at about exactly the same time
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?
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.
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.
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.
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
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.
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...) fill(ctx) end @guarded draw(c) do widget ctx = getgc(c) h,w = height(c), width(c) N=8 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) ) end end show(c)
There’s also an example of handling mouse clicks in the docs.
What happened to Base.colon?
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) )[end] 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) )[end] function move_fig!(color, figure, target) game = color == :white ? white_game : black_game game[figure] = target game = game # update signal end display(scene) move_fig!(:white, 9, (1, 4))
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.
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.