Front ends for Julia codebases?

Offtopic
61

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
62

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”:

https://github.com/makepad/makepad

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

1 Like
63

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.

64

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

1 Like
65

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

1 Like
66

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
67

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.

68

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
69

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

2 Likes
70

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

1 Like
71

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
72

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

3 Likes
73

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 Bar | Quasar Framework

4 Likes