Hey guys,
I’m going to turn a flame-thrower on. You guys may not like what I have to say.
I’m writing this post because of a message that I just received from the developer of Glimmer.jl. Please read Issues · galran/Glimmer.jl (github.com). This message is a real shame because Glimmer is a beautiful piece of work.
Let me describe an 800-pound gorilla that is in the Julia room. I am disappointed that members of the Julia community cannot see the gorilla, or maybe they just don’t want to acknowledge it. The gorilla is a Graphical User Interface (GUI) and an Integrate Development for the GUI.
Apple came into prominence 40 years ago because of its revolutionary GUI. And soon after, so did Microsoft. I am a veteran of Laptop/Desktop application development on Apple and Microsoft platforms. In the early days of Apple, we had to use Objective C, which was the bastard child of Bjarne Stroustrup’s C++. My point here is that Apple proved that the GUI was more important than the language used to implement it.
In the early days of Microsoft desktop development we had to use "Basic". Need I say more...
The reason I’m currently looking into Julia is because of the hell that Microsoft is putting their developers through. Over the years, Microsoft has developed several GUI technologies and Microsoft has finally decided to unify all their GUI systems into a single GUI. It is at the expense of developers like me. They are causing us to completely re-write our entire codebase. However, if Microsoft achieves their goal, they will become a true powerhouse.
I am very discouraged by what I see in the Julia community. At present, Julia developers seem to be content with command-line shell programming. I acknowledge impressive Julia packages like “Makie” that capitalize on the frustration of using Python’s Matplotlib. But this work is not a GUI.
I tried using “Gtk”, but quickly realized that it implements only about 20% of the Tk toolkit, and there does not seem to be any further work on “Gtk”.
Doing application development using a browser is like building a house on quicksand. Web developers do not control their environment. Apple and Microsoft control the environment.
There is a saying in computer development: “Keep up or get out of the way”. Julia package developers don’t understand this axiom.
Charles
Cbrauer@CypressPoint.com
Top comments (16)
Well, there is another old saying, "horses for courses".
Julia is a mathematical language through and through. It was never designed to be a replacement for Swift, DotNet, QT, etc.
And if you like Julia but don't see something you like, why not build it yourself. Put all that experience to something good for the community?
What about these GUI packages?
juliapackages.com/c/gui
One of them should give a decent alternative.
Considering these, the case sounds more like the decades-old issue of open source maintenance stability rather than Julia community's focus on GUI. According to the answer you got on the issue, the stability was lost since a team in Microsoft (Where Ran Gal works) deserted the project. If that will make you go back to Microsoft platform, it's just a bonus for them.
So I think Dash.jl has the best advice on this in their Github page: "Interested in getting involved with the project? Sponsorship is a great way to accelerate the progress of open source projects like this one;" 😉 Money is a stabilizer.
In my opinion / experience Julia is not great for building GUI desktop applications however it is doable and might become better in future. I created a small one a few months back. I would suggest to use: Electron.jl or Gtk4.jl (if you don't want to use any JavaScript in the UI).
The major issue is that PackageCompiler is not working at all or producing gigantic binaries (> 1GB) for very simple applications with a small GUI.
So to run it on a client machine I would just write a setup script to install Julia and create a sysimage to get the startup time in an acceptable range.
However, if there will be good and reliable AOT compilation in future, Electron.jl and Gtk4.jl seem to be good solutions, to me.
So first, Smalltalk did invent and revolutionize the GUI, both Microsoft and Apple copied that from Xerox Parc. en.wikipedia.org/wiki/Xerox_Alto
Secondly, one of the core reasons why I am interested into Julia, is because it has bindings to QML.
And not only that, but well documented, and actually maintained ones as such.
This is truly unique, since Qt/C++ frameworks are notoriously known for being hard to develop bindings for.
The way that Julia is structured, allows for relative ease, when it comes to calling other languages.
QML has a (well hidden) UI designer, that allows you to design the UI via drag and drop.
The only possible way, to increase the UI capabilities of Julia in a significant way, that I can see, is to create bindings to Godot.
medium.com/swlh/what-makes-godot-e...
Hmm I know that problem too... I've been needing a .NET - julia interface since my very first days of julia, and we had a lot of discussions about this on the discourse (see e.g. discourse.julialang.org/t/correct-...).
So far there does not seem to be any streamlined way to interact, but damn that would be nice to have both julia flexibility and .NET interface robustness !
I know this isn't how much Windows software works but a common (but imperfect) approach used in the Linux world is to shell out for analyses etc. Doesn't work with every workflow but it does "function".
No matter what you do, a GUI toolkit will not be Julia all the way down. Glimmer.jl was mostly JS, I believe...
For sure, I'm more regreting the absence of a package for interop with .NET rather than a full julia capability to do this.
There are many packages available for Julia to .NET integration, one for calling from Julia, and this one to call from .NET to Julia (previously allowed both ways), which seems appropriate for a GUI:
github.com/HyperSphereStudio/JdotNET
Since it's a .NET package, and C# the main language (F# etc I believe also supported) you should be able to use any C# code, and any C# GUI toolkits (and GUI designers for), native for Windows and/or cross-platform. The GUI parts, and C#, should be as smooth as anything available for C# at least (if not for any other language). I've not used any of the .NET integration packages for Julia (nor for Java, JavaCall.jl in not in-process; what I would like and I think that package provides, same as e.g. PythonCall.jl). .NET, and C# are now cross-platform, available for Ubuntu and macOS too. If the GUI stuff isn't good there then it's because of the .NET and/or GUI toolkit, not Julia.
You might think either C# (or any .NET language) needs to be the language you start, for a GUI, and the only other option starting with Julia calling .NET, but there's also a third option a fork of Julia for .NET:
github.com/HyperSphereStudio/Spinor
I see also a demo GUI:
github.com/PiResearchTech/Ayudha
Note also my first comment here on Mousetrap.jl in case native Julia better, based on GTK4. GTK4.jl is also available but claimed not as easy to use GTK4 directly, well through that. Qt.jl/QML.jl is another option, and using a game engine, i.e. Godot seems very intriguing (I just discovered it; i.e. using it for a GUI in this thread, not yet with Julia though). Makie.jl has been used for a game, a Minecraft clone, so also similarly an option for a GUI, though likely not yet well-developed for such use... Mousetrap seems very good already, and with Makie would be even better (which has been proposed). And web "GUI" options are already a possibility Genie.jl and related (and Dash.jl), even no-code UI designer most recent option, GenieBuilder.
Yes, I know of these examples, they actually have been mentioned already in the thread I linked from the julia discourse. I do not say there are no interop examples. I just mean that for .NET there is no consolidated package such as PythonCall or CxxWrap which would facilitate adoption.
You did state (and "regret") "the absence of a package for interop with .NET", and if you misspoke or found out later doesn't matter. I thought you didn't know and wanted to help you and others. I don't know which package for this is best yet (may depend on calling direction, I think I found best for either). I may find out (for sure) when I care. With .NET might be best or not for GUIs, but I'm not yet convinced .NET with or without Julia is best for that (it's plausible), I would like to know if some of the other Julia options are already very good or better. There was also a new QML.jl just recently announced (after I answered you), so not just Mousetrap.jl is new.
Ha yes my bad, apologies for the "absence", that was a bit much indeed. I have no argument about the quality of .NET for GUIs, pro or con. But .NET is quite widespread and having a streamlined way to make julia and .NET work together would just be great. Who knows, maybe Microsoft will put some people on that !
I signed up to answer this. You might not not know of the recently announced:
discourse.julialang.org/t/a-new-ju...
Mousetrap based on GTK4 (but simplifying, claimed better than GTK.jl) may be better than the alternative Qt/QML. I see it used, be a very intriguing project (seemingly from Julia QML/Qt is simpler, than from its native C++, just GUI/MVC difficult, and the concept would be for any beginner):
forem.julialang.org/janiserdmanis/...
If web-based "GUI" is an option (some seem to prefer to traditional desktop GUIs, for good reasons or out of ignorance...?), then Julia is also covered, with e.g. Genie.jl (or Dash.jl, or Oxygen.jl), the first two projects at least with company support, and Stipple.jl and the no-code UI GenieBuilder designer.