I clearly have had way too much time on my hands lately because I have begun to investigate developing a gui toolbox and widgets similar to GTK or Qt only written in pure Julia. My reasons for this are:
that for the life of me I cannot figure out GTK, no matter how many tutorials I watch,
GTK does not seem to play very well with Julia although it is just as likely to be me not being able to play well with GTK
GTK and Qt do not have direct support for Julia
Julia’s format and syntax it’s bound to be easier to use,
implement the speed of Julia in GUI development
And I really don’t want to learn C++ just to make a simple database input form (which truth be told is all I really want to do). I am only a simple biologist.
And (in case you haven’t figured it out) I’m kinda up to here with the available options
If there is already a project out there doing this, I’m not looking to steal thunder and will gladly contribute to that project.
Unless you’re really passionate about spending the next 10+ years of your life doing this at the same time that you learn the domain you’re working in, I would encourage you to invest your time into learning how to use the existing Julia bindings like GTK.jl and then build an alternative API on top of them that you find more accessible.
To understand why I’d recommend that route, consider that GTK has ~72,000 commits made so far to its codebase. Under an extremely rough approximation that a full-time software engineer can produce about 1,000 commits a year, this is 72 years of full-time work. Of course, this is rough approximation, but it’s probably right that somewhere between 10 and 100 years of work have gone into GTK. So if you’re going alone, you’re signing up for that timeline.
I have been working with Gtk.jl and the documentation is very incomplete. Not exactly sure why but that is the reality. Makes it very difficult to know which widgets, properties, and actions are supported. Not all are.
While I appreciate what you are saying here, if the developers of Julia took this advice we all wouldn’t be here. We already had Python, C(and it’s endless versions), Java, R and so on that were sufficient to have solved many many problems. But there was a reason (or reasons) why Jeff, Alan, Stefan, and Viral chose to go through the decisions and frustrations and endless commits to bring the rest of us here a fabulous new language (the name I’m not 100% happy with as it is the name of an ex where it didn’t end well, but that’s my issue). The amount of work that needs to be done doesn’t phase me, from where I sit it becomes, do I have the knowledge and skill to pull it off, and I certainly do not have the answer to that, yet.
I certainly empathize with your frustrations with GTK.jl.
In my experience, I ended up having to often post questions and issues on the repository for help or refer to the GTK documentation.
To @johnmyleswhite 's point, I certainly concur that you will have more resources but as you stated and I agree with, finding them will be a challenge as it is right now.
It would be amazing if you could sink time into building GTK.jl’s documentation and interface out more as I certainly think it has an amazing future if we can get it better supported in Julia.
Could be a good Google Summer of Code project for sure!
But, I do see your point @SergeantMike67 of creating something novel for the Julia ecosystem - or something at least better suited to Julia.
What would be super fascinating given what @jzr recommended, is if you could build on top of Genie.jl and the Genie ecosystem to perhaps make GUI windows inside Electron containers.
I know some folks have qualms with GUIs built with Electron due to large memory consumption at times.
However in a case like this, with the extensive work and framework in place that @essenciary has done with Genie, I would think utilizing those tools in Electron would be more than appropriate!
Otherwise, best of luck!
Sadly, I do not know of great GUI building tools to get you started with but I am curious if you begin to build anything!
I felt it is easier to use MATLAB’s programmatical GUI interface. However, making an OS independent GUI interface is not easy and usually this kind of thing builds on top of GTK or QT.
I started looking into building a pure Julia GUI toolbox, but at the moment julia doesn’t provide all the infrastructure (read as: compile-to-static, automatic ccall generation from a FFI description, multi-threading for interactions, GC-free operation) so one/you/me would end up in similar problems like time-to-first-plot. And do a GUI thing (fully-) system independent shows a lot of areas where even system dependent solutions are missing (my favorite: select a font to display all glyps in a string …). There might be a future where the julia problems all have been solved.
For the time being i recommend to deal with GTK.jl - even if the documentation is not fully available, a lot of basic and advanced things work (e.g. Glade - the interface builder). Or go to a browser based interface.
Thank you @lobingera this is highly useful information. If the base infrastructure does not exist then it becomes an exercise in futile frustration. Perhaps it is wise to wait for the infrastructure to catch up with the idea.
I have been using Glade and find it rather frustrating to not find out why what I want to do is not allowed. It just doesn’t happen, no explanation, e.g. Entry box completion. What I do is not accepted without a reason why.
Perhaps what we need is a wrapper library, mostly written in julia, which provides a set of easy-to-use APIs for writing simple GUI interfaces.
An example of an easy-to-use API: PySimpleGUI
Although PySimpleGUI has its own goals: “Getting Over the GUl Bar”.
I mentioned it mainly to illustrate the easy-to-use API.
Another amazing example:
cross-platform declarative UI + reactive GUI
Red is a next-generation programming language strongly inspired by Rebol, but with a broader field of usage thanks to its native-code compiler, from system programming to high-level scripting and cross-platform reactive GUI, while providing modern support for concurrency, all in a zero-install, zero-config, single 1MB file!
Do you have a concrete example? issue on GTK.jl? Autocompletion in e.g. a Text Entry is really advanced magic and involves connecting signals - do you mean something like this Entry ?
I made an early attempt to use Red but I’m disappointed with all the delays in implementing a 64 bits Red language. Seriously, restricting to 32 bits makes it completely uninteresting.
I don’t think it’s all that crazy since interactive plots are GUI, and we have a couple of “pure” ones in Julia already.
I think if you wanted to give it a try you would need to focus on making writing widgets as easy and elegant as possible (rather than trying to provide already made widgets for every use case). So think about what it takes to specify what is a button or list of a dropdown menu and try to offer an API that allows to write it down with a minimum of boilerplate.
The GUI framework itself needs to be able to deal with windows, events (mouse & keyboard inputs), drawing things on the screen (hopefully in a smart way), interaction between widgets, etc.
I actually tried to write something to abstract the backend (SDL2 or the OpenGL stack), but never got very far with it (I think it worked though).
Also there’s GUI and GUI, having a couple of menus, buttons and sliders should be pretty achievable (already possible with makie ?), but a complex app with lots of windows, rich text editor, etc. is a bit less realistic.
I just stumbled over https://dioxuslabs.com/ the other day. I think something along those lines for Julia would be cool, and while still very ambitious, doable in finite time.
The difficulty here would be also making such GUI cross-platform. This is largely why GTK or QT exist. They are cross platform GUI environments. One could build up a GUI using Win32 API with ccall, but that would not be cross platform.
If you just want a database input form, I would consider making a web-based frontend for a Julia based backend.
There is some existing work in the https://github.com/JuliaGizmos organization. In particular, I would look at the Interact.jl family of packages and their Observables.jl successors such as GtkObservables.jl as mentioned above.
You could check out Glimmer.jl It’s a registered Julia package. Very early in its development so it may not have the range of features @ SergeantMike67 is looking for. Documentation is sparse but run
Glimmer.runExample("Controls")
to see what functionality is currently supported.
It is platform independent. We wrote it because we needed faster 3D rendering than we were getting from Makie.
I can explain this. I wrote the current docs (or the initial part of that) in my spare time and had only a limited time window. I thus concentrated on making it more a tutorial style docu instead of replicating everything from the real Gtk docu. So yes, the Gtk.jl docu is more an intro. Afterwards one requires the Gtk docu. But given that Gtk.jl is a binding to Gtk: Doesn’t that approach make sense?
