Front ends for Julia codebases?

Winston will work in the future. I keep it going since it is used in a large in-house software of mine.

Plots.jl is only one option in julia. Certainly not the one and only. Wrapper libraries are always a compromise.

3 Likes

Good to know, maybe I will look into winston for these purposes then! It may have advantages I’m unaware of in it’s API as well.

My adventures with making GTK plots interactive can be found here: Plots.jl Plot Coordinates - An Adventure

The last Gadfly release was July 15, and latest commit to master was 3 days ago.

Makie also has a Cairo backend and is maintained. This is well beyond my expertise, but it’d be great if you could use the OpenGL backend. I’d definitely look into it if you’d like to do something fancy and interactive.

Personally, I’ve avoided using Plots.

EDIT: sdanisch is one of the main people behind both Makie and PackageCompiler, so if time-to-first plot is a concern, Makie should work well with it.

2 Likes

Interesting, maybe I misunderstood what it meant that Gadfly was deprecated as a backend for plots(https://docs.juliaplots.org/latest/backends/). Good to know about Makie. I’ve used it with Cairo before, no clue how hard it would be to hook into a UI that wasn’t JS?

Why have you been avoiding plots?

Elrod - I used to be very comfortable with OpenGL once upon a time. We’d need some convenient hooks into Julia to really get things moving. I see GTK supports GL frames, but there’s no examples with them being used for anything. Similarly, CImGUI I believe has hooks into OGL. Really half the battle for me right now is figuring out how these libraries are implemented, most of them have zero doc’s. So being able to contribute to one of them support GL hooks could be really hard… Who knows maybe it’s already in one of these packages? :slight_smile:

There is one aspect of CImGUI that you should be aware of. It’s a very power hungry solution. See some discussion here

1 Like

30% of your GPU just to spin up a few windows? eek. Yea I am going to stick with Gtk first then. But, I intend to experiment with it nevertheless. The built in plot widgets are an attractive solution to scientific applications. At the cost of some GPU? Might be a fair trade :smiley:

GTK

So I was able to get GTK running with Cairo in Julia 1.3 - no hitches whatsoever. For me, this is the solution I was looking for. Why?

  • It’s platform agnostic
  • It’s easy to write event listeners
  • Custom widgets can be made with GtkCanvas, and a little elbow grease
  • It’s fast(at least fast enough for me not to notice any slowness). Also, it precompiles quickly enough.

So what’s the deal? If you read through the garbled mess I wrote in this thread you’ll see I started via writing hooks between the JVM and Julia to leverage JavaFx’s tooling. What I found was that writing hooks to Julia for close interop was really painful, even by cheating and directly calling background Julia processes there was too much developer overhead for me to meet the goals I want to meet without a team of people.

By making the same custom, and boiler plater UI elements from JavaFX into Gtk I noticed some things… The custom interactive plot solution I wrote in Gtk worked noticibly faster then the baseline JavaFX linechart widget. Handling the collections in Java, despite it being a language specialty, was laggy for largish data because of how I designed it, and how LineCharts.java works.

By making the same custom menu widget I want in the tool I’m working on(yes the menu is actually integral to the tool itself - I won’t explain), I reduced my java code from ~5 class files and 600 lines of effort(very little boiler plate because this was a prototype effort) to 1 file, with recyclable methods (useful for both widgets) in <180 lines of code.

So, development is less painful, more generic, in one language(okay two because GTK is C++, but its not C++ I have to write!), and more efficient.

My current conclusion is that, there’s no reason to really leave Gtk right now. I haven’t run into any dead ends that made me turn around yet. Highly reccommend trying the latest version Gtk.jl out if you haven’t already and need a desktoppy UI that isn’t painful.

For WebUI’s anyones choice or guess is better then my own.

2 Likes

I have a hard time imagining what the software you describe is used for. Are you writing some sort of IDE? Could you post a brief screen capture to illustrate?

1 Like

Talking about IDEs, this is an example of in-browser IDE without much JS code, “that compiles to wasm/webGL, osx/metal, windows/dx11 linux/opengl”:

and running IDE app: http://makepad.nl/

1 Like

Petr - Specifically I am not working on anything… I’m more so exploring things. I have some physical simulations that need a front end thats fast and close to huge hunks of data. I also have physical simulations that have tons of parameters and they need a front end that doesn’t stink otherwise I’ll lose motivation in pursuing that hobby. I also play with hardware stuffs, and microcontrollers, and having a front end there can be diagnostically helpful. Sure, nothing wrong with consoles, and plot windows flying around, or directories piling up pngs, but it helps me to see what’s going on to have a tool cut for the job.

I see. Still, should this become something generally useful, I think I would like that a lot.

1 Like

I feel like those involved in Makie might be able to provide some good suggestions here. Just a thought.

1 Like

I think so. Right now I am wrapping what I’ve done into a package. It’ll probably be 50% UI 50% convenience functions for those UI elements. Might factor out some of the I/O stuff I’ve done… If it ends up not being a jumbled mess I’ll packigify it. If not I’ll try to contribute to Gtk :).

1 Like

I’m very interested in Makie but found it to be quite slow for my GPUless laptop. I’d love to see Makie embedded in Gtk :D. I think there’s a lot of potential for Makie to be extended to something it’s not directly intended to being, but I assume that crew are already on it, and don’t need a hack like me contributing.

My latest builds of Makie work fine after the first plot and I don’t have a nice GPU.

don’t need a hack like me contributing.

Isn’t that where most of us are at ;). They’re super patient if that’s your main worry. But if your happy with your current approach keep it up. Sounds interesting

1 Like

Would you happen to have this code available somewhere ;-)?

2 Likes

Sorry everyone GTK is written in C not C++. Not sure why I said that.

1 Like

I am currently working/playing on a application and decided for CImGUI and I like it very much!

The GPU Load of 30% (or more) seems to be not true for me. I have a plus of 4% roughly on a GTX 1070 (GL backend for ImGUI which is the default with Julia).
This is measured with my own application running, not with the demo.

I think there are several reasons:

  • the demo is a full blown up showcase of all features of ImGUI, a real use case will only use a fraction of the possibilities
  • you can take full control of the update loop of the GUI which i have done in my case. This looks like:
realtime=Dates.now()
elapsed_realtime=0
while ! action.stop && display.isOpen
    ... #do my own stuff
    elapsed_realtime=Dates.now()-realtime
    if Dates.value(elapsed_realtime) > 16
        realtime=Dates.now()
        elapsed_realtime=0
        display=display_update(display,ws,action)
    end
end

This is calling the GUI update only about every 16ms (which is than 60FPS, not exactly, about 55FPS if my own code is running in between). This can easily be reduced more, until the GUI feels unresponsive. Updating every 16ms is btw also the default in the core of ImGUI: if you run the GUI loop without own constraint you get 60FPS too but it seems that it costs more of the GPU. I think because of the window begin calls and widgets which still put load on the GPU. But, as stated, this can easily be avoided.

Having full control over the GUI update loop is a great advantage, because you can control how much your real algorithm get to run. No need to split GUI and worker threads to get full CPU load on the algorithms. Clearly the GUI can freeze with this approach, but this can easily be communicated through the GUI to the user (if needed).

All in all using CImGUI feels very natural and Julia like for me.

There is the only drawback for me, that you have to read the usage and examples from three different sources: CImGUI.jl ,ImGUI and GLFW and mainly just from examples. This makes it sometimes difficult to get the information you need.

TL;DR: CImGUI.jl recommended :slight_smile:

2 Likes

I’m also looking for a good and easy way to build GUIs.

3 Likes

For Stipple, there will be Blink support for building Electron based desktop apps. This will make a powerful combination with the web UI (based off Quasar) which provides app elements, ex https://quasar.dev/vue-components/bar

4 Likes