Like hackers who prefer to use terminal than Desktop Environment. Some prefer JULIA without GUI as long as they get what they want in the end, less is more.
Not intended to make GUIās manditory for all uses. It is essential to have the option available should your application need it. You want to continue using command line? Go for it
What do you mean by that? I donāt know any way to make GLMakie more native besides developing our own hardware drivers - which doesnāt seem to be a productive goal ^^
I think here ānativeā means āusing the native toolkit of the desktop environment so that it is styled seamlessly like any other system app, it supports system themes, accessibility, etcā. That would mean using GTK on Gnome systems for instance. While I love Makie, the buttons you get in Makie definitely do not follow the default colors and fonts of my system. Even tab
to switch between selected buttons does not work.
You cannot even select buttons All this accessibility stuff had to be cut because I had no time, it would be better if it was there, but there were no resources to do it, and in the end itās a plotting library, not a GUI toolkit. I donāt know how much time was poured into GTK and the like, but probably a million times more
No, I used ānativeā as synonym for āpure Juliaāā¦
Well, if you write a GUI for scientific code most of the features of GTK and co are not neededā¦
For example, currently I write code to be used by SW testers, and they would already be happy about a simple GUI with a few drop down lists and buttonsā¦
Makie has all features needed for that, just no GUI builderā¦
You got me good there for a minute
I have the feeling Iām just recalling something already said before, but isnāt this kind of no-code editor what the Genie guys try to achieve ?
Some of my scientist colleagues are blind. They would certainly appreciate the accessibility features being there.
But as @jules mentioned, Makie is already an amazing piece of software created under incredible workforce constraints, so it makes sense that a lot of the typical āGUI toolkitā features are missing from a āplottingā library.
Indeed, Genie Builder v0.2: speed up your Julia app development is a kind of GUI builder, but only for web-apps, and classical desktop GUIs are usually not web-appsā¦
But I guess they would be happy with a text-based interface and would not require a GUIā¦
I have actually been asking a lot of questions about .NET <-> julia compatibility since I started using julia, and some efforts have been made by people much more capable than myself. If you want to have a look at one, see GitHub - HyperSphereStudio/JdotNET. It is not pure julia for sure, but the goal is to combine the best of julia and .NET, which seems in itself a pretty nice objective.
@Alon I fully agree on the importance of using GUIs for interactive modelling, but you may be a little strict in your definition of GUIs.
Iāve used Interact.jl with ModelParameters.jl to automatically build interactive web interfaces for models
An example use-case in:
You donāt need drag and drop components when you can generate controls from the structure of the model. But of course this is a limited case, only the sliders are being generated.
I think GLMakie.jl is the future of interactive modelling in Julia, and where I am currently building interfaces - mostly completely with code. But an interactive GUI builder shouldnāt be too hard to make? The main problem currently is itās much too slow to load, but hopefully that comes down.
It would be amazing if we could do Revise.jl updates with a currently running instance of GLMakie.jl, but Iām not sure if its technically possible. Right now you have to restart the interface to get the latest version of you code.
I am not opposing web technology for GUI. It would be wonderful to have. If you could use a tool like whimsical.com for example and then assign Julia functionality to buttons, textboxes, sliders, etc. You can always wrap a web app in a window that is essentially a browser and serve it as a local app. Iāve done this with streamlit.io
The point is to create a GUI with no code, and then continuously edit it, add and remove UI objects while developing the code. Tools for creating a GUI visually and converting it to code are useless because once you edited the code (added some data processing or whatever) you canāt go back to the tool and change the layout without going back to square one on the code.
Perhaps so.
I could live without the Revise aspect. But (1) the idea that the GUI needs to be created by drag&drop and (2) that it needs to be editable (adding/removing buttons, graphs, dropdown boxesā¦) are critical imo.
I can see the appeal for drag and drop widgets. Iāve hacked simple editable interfaces together for specific purposes with Interact.jl, but not for the general case of dropping arbitrary widgets and access them from code.
Both Makie.jl and Interact.jl use Observables for communication between interfaces and code - I guess you could add these to the figure object via the interface and access them in the object somehow in your code? It would be a cool project to prototype that. We just need someone to do it. Those Matlab apps are pretty slick⦠it will be a lot of work to match.
Also it seems that mathworks App designer doesnāt have live code reload either, in the video they are hitting run after any changes. Thatās totally possible already in julia just using revise and running your app function.
Possible repeating some earlier arguments, but here are my thoughts:
Lots of people here are scientists (or similar). We know our models and a bit about how to code them. But, mostly little about GUIs.
Still, it would be nice to have some simple (and easy to use) tools, especially for teaching material. Like āletās see what happens if we change xā¦ā and then a slider. If anyone could provide that, then it would be much appreciated.
Did you try Pluto? Itās great for this kind of interactivity.
Yes, Iāve tried it. Cool, but a step too far (everything changes everything) for what I can handle.