Well, I would not say it is unnecessary… GTK has a lot of disadvantages, Glade is terrible and you end up reading C library documentation…
QML is broken on 1.7…
imgui has a huge drawback. It’s barely usable from laptops because it puts the gpu running at 100% all the time. I don’t want mine to melt that way.
As I referred before in other posts about this. My hopes were in libui and even made a wrapper once but the libui project looks dead, though there are still people trying to resurrect it.
Okay, but how much is necessary to rewrite to achieve that? Could it be in a package on top of GTK.jl or not? The GTK.jl design seems the same of many solver wrappers (Gurobi.jl, CPLEX.jl, GLPK.jl, Xpress.jl) that is: just wrap every function automatically and point to the original documentation (often C/C++). JuMP then enters as a layer above all of them which allows writing mathematical models without worrying about the specific solver and its peculiarities. The problem here is that, as there is no layer above GTK.jl, it is not worth converting all documentation with small changes to Julia, nor the code follows what would be Julia design patterns. A package above GTK.jl (instead of replacing GTK.jl) could take care of these problems.
This is an unnecessary splitting of hairs. I think it was very obvious what I was talking about with the OP given the current state of the Julian infrastructure. I don’t believe that the creators of GTK or QML were asked to parse out their use of words in such a manner. I guess my mistake was not including the phrase “native Julia at a level most reasonable developers can use without having to re-write the entire operating system in Julia.” I’ll try to be more specific in the future
Gtk.jl actually does abstract quite a bit from GTK already but it’s true it could be improved to hide the library more. That said I think it’s very hard to get away from GTK logic and design without encountering some serious issues. For example if a user wants to update part of the GUI at regular intervals, it might not be safe to do it from Julia’s side, because you can invalidate GTK objects and that will lead to random segfaults (Gtk apps can be a nightmare to debug). Instead the user should add a callback to GTK’s main loop, so it’s hard to hide these concepts completely.
Working on Gtk.jl is also difficult because you need to have a good understanding of both GTK and Julia’s internals. A lot of GTK designs are also linked to C limitations (GTK has it’s own pseudo object system, memory management,…) and presumably one could do something better in 2022.
While someone may still need to understand C to do move this forward via libwayland, it does seem plausible. Eventually, it is also may be possible to implement the Wayland wire protocol directly in Julia without needing to depend on libwayland C library.
@caleb-allen I think you are getting the gist of the original idea along with @jonathanBieler and @ufechner7. There seems to be a lot of folks on this thread that like to look at a problem and see all the things that can go wrong and say it can’t be done or shouldn’t be done. If you or anyone is willing to risk abject failure and embarrassment tilting at this windmill and possibly come up with something useful, elegant and Julia based towards this end, I am willing to set up a Git Repositorynot that I have a damned clue on how to do that but there are tutorials, and start dedicating time to it. If not then I am perfectly willing to table this discussion until a later release.
Okay, and what level is that? This includes rewriting GTK.jl or not? Or it will build above another library like QT? It will support X11, Wayland, Windows, or focus on just one of these? These are things that need to be defined before starting the project.
personally, I’m skeptical of the viability of user interface-toolkits that don’t target the browser (or adjacent technologies) for at least one of the backends.
I would be interested in a GUI toolkit that does not build on top of GTK (problematic programming model) and not on top of QT (license issues, large, C++ not so easy to integrate with Julia).
It sounds a web-based solution will perfectly fit your requirement. I used to write a Flask-based app (Python) to handle my simulation data. I believe in Julia domain maybe Genie or Dash will do the job well. It works perfectly for such tasks.
Exactly. Without some bit of pre-compiled code doing the heavy lifting a pure Julia GUI would be a nightmare to use. Which means either good binary caching in Julia itself or system images containing the GUI code. Or, of course, just use a compiled library such as GTK as a backend.
I love Julia, but honestly at this stage I think it’s just not the right language for GUI development (or similar things, such as games).
This actually happens in Gtk.jl (presumably because callbacks & wrapping code need to be compiled), it doesn’t seem much better than in Makie. I think all this GUI talk needs to assume we’ll have good binary caching at some point.