Okay, I expressed myself badly. I meant to say that I never saw a reason for coding a GUI for standard data input in research. If your research is about GUIs, or anything visual/motor, then you may need a GUI because the input you are capturing is not standard and you need to define and implement the way to capture said information. However, I hardly see the reason to use a GUI for standard fields (the kind that are available in a online survey solution) unless you surreptitiously are trying to obtain data on usability of said questionnaire (so, again, the real input is nonstandard).
What standard is this? Iāve never encountered online surveys or questionnaires in my research. Again, research fields are different.
7 Likes
I do not know how your data is structured or how much of it there is, but in my project I am dealing with large numbers of data points. For example, my inventory of wasps currently numbers over 30,000 of which I need to know the sex, location, emergence date, emergence time, species, variety of plant it came from and eventually a genetic varcode identifier and probably a number of other pieces of data I havenāt even thought of yet.
To enter this amount of information that cannot be generated electronically accurately and efficiently without a GUI is sheer madness. If you believe otherwise, I am willing to send you my latest datatsheet of emergences (numbering close to 1000 wasps, and a copy of the database without a GUI for you to enter the data.
2 Likes
You do not necessarily have to use an external web browser. For example, you could use Electron via https://github.com/JuliaGizmos/Blink.jl
In this case we are just using Electron as a rendering engine.
4 Likes
I guess we are talking about very different things. Data entry isnāt really an issue in the cases Iāve seen, except for setting up measurement parameters, for example.
Gui use is in my case mostly about loading data, browsing, filtering and processing in various ways, directly interacting with a visual representation of the data.
This is a totally different domain from what you are probably thinking of.
What Iām trying to figure out is what a āpure Juliaā GUI even looks like. If we are not going to use a cross-platform framework like GTK or web based rendering engines, then we are down to making calls into operating system specific UI API, which involve even lower level calls into something like the Win32 C API. You have to call something to make a window.
So what did you have in mind? How does one create a window? How do we draw a line, so one could create a box that looks like a button?
3 Likes
If I am able to get my study subjects to consistently and accurately enter their own data through an online form, we would be talking about a whole different area of research. My insects are not that well trained and given that they only live 4 days as adults, itās gonna be tough to get tens of thousands on board for the next round of data collection.
2 Likes
Makie has these basics figured out via GLFW & OpenGL 
One could also think about a GLFW & Cairo based framework.
It never was intended to be a fully fledged GUI framework, but I always wanted it to offer at least basic UI elements.
Who knows how it will grow, if people have serious interest in improving the UI capabilities!
13 Likes
You are thinking to narrowly. Gtk is written in something right? Someone didnāt write it all out in 0ās and 1ās, yet it is cross platform. How did they do it? They used a complied C++ program and If they did it in C++ then eventually is should be able to be done in Julia. I get that we are not there with Julia yet.
Itās typical to write an abstraction layer to make different graphics libraries appear uniform. One could do that from Julia, but you eventually need to call the underlying (OS specific) graphics library. I think that is what @mkitti is getting at in it not being pure Julia.
1 Like
GTK is written in C, not C++, and it builds upon the GDK, the Gimp Drawing Kit. This in turn calls the C APIs of X11, Wayland, Quartz, or GDI (Win32).
Are you proposing that we also bypass that layer?
Oops I have made the unforgivable mistake of getting the wrong flavor of a programming language wrong. I stand corrected but it doesnāt change my point.
No of course I am not proposing any such idiocy. I cannot tell if you just arenāt getting this or are being purposely obtuse. All I simply proposed is to create a GUI development package written in native Julia, to make it simpler and more efficient for Julia programmers and here we are 40 some posts later asking if I was proposing rewriting whole operating systems in Julia in order to accomplish this. If you want to extrapolate my original post to this degree you are of course free to do so, but these are your proposals not mine.
Oh, for this I use Jupyter. Well, I can see how all these phases benefit from a GUI, especially the ādirectly interacting with a visual representationā, but I was under the impression we were discussing a small GUI for data entry, because after that the data is in a CSV format (or similar) and can often be processed without constant user interaction.
I think thatās probably the crux of the miscommunication here. The discussion has gone to many places, but then one post sweepingly claimed that āresearchers donāt need GUIsā, and similarly sweeping statements were also made.
I donāt think the OP was inviting such a narrow discussion, and at least it wasnāt obvious.
In that case youād have to implement the Gui inside jupyter. I donāt know how possible that would be.
The problem here seem to be what you mean by native Julia. As @mkitti pointed out, it is not viable to have Julia all the way down, so what you mean by native Julia is confusing. If you accept that at some point the layer under will not be Julia, well then what would be the benefit such package would have over GTK.jl or even a package built over GTK.jl?
4 Likes
Well, the benefit would be to have source code and documentation that are consistant, use Julia design patterns and are easy to debug and modify by Julia users if neededā¦
And it would be less likely that the library brakes when a new Julia version is released as it just happend with QML.jl ā¦
5 Likes
I think the design goal is that donāt want the user to have to deal with any of the C libraries for most use cases, you should be able to stay in pure Julia for most reasonable applications, so the C libraries should be quite low level and behind a few Julia abstraction layers (Makie level is probably the right one). Gtk.jl gives you the impression to be in Julia but if you scratch a bit the surface you quickly realize itās an illusion and you have to go read some C code.
4 Likes
Thatās good to know we are not writing JuliaOS. So perhaps letās start with Wayland.
Someone did attempt to write a Wayland protocol implementation in Julia, although it appears the effort is now abandoned.
This was a side project I abandoned due to mounting difficulties and the realisation that bindings for the C library are simply more sensible to do at the moment. Leaving it as-is in case it helps someone.
Can we use the Wayland C library?
1 Like
I think this is a great idea, and Iāve wanted something like this for a while.
I have worked in mobile development for ~8 years (android), which may perhaps offer a nice parallel. On Android, Java isnāt exactly ānativeā as the framework is written in C and C++, but the abstractions from within Java are enough that youāre completely insulated from ever writing C.
Whether through something like GTK or not, I think there is a place for an extensive julia-based UI Toolkit which insulates a user from worrying about C based frameworks
4 Likes