# Front ends for Julia codebases?

**URL:** <https://discourse.julialang.org/t/front-ends-for-julia-codebases/31370>\
**Category:** Offtopic\
**Created:** [November 22, 2019, 2:29am UTC](https://discourse.julialang.org/t/front-ends-for-julia-codebases/31370 "2019-11-22T02:29:28Z")\
**Posts on this page:** 13\
**Page:** 4

<div class="post-metadata">

**Author:** ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)\
**Post date:** [January 1, 2020, 4:48pm UTC](https://discourse.julialang.org/t/front-ends-for-julia-codebases/31370/61 "2020-01-01T16:48:21Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![sairus7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sairus7/32/10816_2.png) [@sairus7](https://discourse.julialang.org/u/sairus7)\
**Post date:** [January 1, 2020, 5:57pm UTC](https://discourse.julialang.org/t/front-ends-for-julia-codebases/31370/62 "2020-01-01T17:57:05Z")

</div>

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](https://github.com/makepad/makepad)

and running IDE app: [http://makepad.nl/](http://makepad.nl/)

---

<div class="post-metadata">

**Author:** ![anon92994695](https://avatars.discourse-cdn.com/v4/letter/a/ce7236/32.png) [@anon92994695](https://discourse.julialang.org/u/anon92994695)\
**Post date:** [January 1, 2020, 8:02pm UTC](https://discourse.julialang.org/t/front-ends-for-julia-codebases/31370/63 "2020-01-01T20:02:28Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)\
**Post date:** [January 1, 2020, 9:30pm UTC](https://discourse.julialang.org/t/front-ends-for-julia-codebases/31370/64 "2020-01-01T21:30:12Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Zach\_Christensen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zach_christensen/32/7220_2.png) [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)\
**Post date:** [January 1, 2020, 9:56pm UTC](https://discourse.julialang.org/t/front-ends-for-julia-codebases/31370/65 "2020-01-01T21:56:38Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![anon92994695](https://avatars.discourse-cdn.com/v4/letter/a/ce7236/32.png) [@anon92994695](https://discourse.julialang.org/u/anon92994695)\
**Post date:** [January 1, 2020, 10:45pm UTC](https://discourse.julialang.org/t/front-ends-for-julia-codebases/31370/66 "2020-01-01T22:45:17Z")

</div>

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 :).

---

<div class="post-metadata">

**Author:** ![anon92994695](https://avatars.discourse-cdn.com/v4/letter/a/ce7236/32.png) [@anon92994695](https://discourse.julialang.org/u/anon92994695)\
**Post date:** [January 1, 2020, 10:47pm UTC](https://discourse.julialang.org/t/front-ends-for-julia-codebases/31370/67 "2020-01-01T22:47:55Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Zach\_Christensen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zach_christensen/32/7220_2.png) [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)\
**Post date:** [January 2, 2020, 1:15am UTC](https://discourse.julialang.org/t/front-ends-for-julia-codebases/31370/68 "2020-01-02T01:15:37Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![KajWiik](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kajwiik/32/199_2.png) [@KajWiik](https://discourse.julialang.org/u/KajWiik)\
**Post date:** [March 18, 2020, 5:53pm UTC](https://discourse.julialang.org/t/front-ends-for-julia-codebases/31370/69 "2020-03-18T17:53:44Z")

</div>

> [@jpsamaroo](#):
>
> I managed to port one of the node editors to Julia

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

---

<div class="post-metadata">

**Author:** ![anon92994695](https://avatars.discourse-cdn.com/v4/letter/a/ce7236/32.png) [@anon92994695](https://discourse.julialang.org/u/anon92994695)\
**Post date:** [June 10, 2020, 10:27pm UTC](https://discourse.julialang.org/t/front-ends-for-julia-codebases/31370/70 "2020-06-10T22:27:02Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![oheil](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oheil/32/220745_2.png) [@oheil](https://discourse.julialang.org/u/oheil)\
**Post date:** [June 11, 2020, 10:40am UTC](https://discourse.julialang.org/t/front-ends-for-julia-codebases/31370/71 "2020-06-11T10:40:45Z")

</div>

I am currently working/playing on a application and decided for [CImGUI](https://github.com/Gnimuc/CImGui.jl) 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:

```julia
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](https://github.com/Gnimuc/CImGui.jl) ,[ImGUI](https://github.com/ocornut/imgui) and [GLFW](https://www.glfw.org/) and mainly just from examples. This makes it sometimes difficult to get the information you need.

TL;DR: CImGUI.jl recommended 🙂

---

<div class="post-metadata">

**Author:** ![Juan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/juan/32/7657_2.png) [@Juan](https://discourse.julialang.org/u/Juan)\
**Post date:** [June 11, 2020, 11:05am UTC](https://discourse.julialang.org/t/front-ends-for-julia-codebases/31370/72 "2020-06-11T11:05:45Z")

</div>

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

> **[GitHub - JuliaGraphics/QML.jl: Build Qt6 QML interfaces for Julia programs.](https://github.com/JuliaGraphics/QML.jl)**
>
> Build Qt6 QML interfaces for Julia programs. Contribute to JuliaGraphics/QML.jl development by creating an account on GitHub.

> [@Stipple: Reactive data dashboards with Julia \[WIP\]](https://discourse.julialang.org/t/stipple-reactive-data-dashboards-with-julia-wip/37291/10):
>
> The data table API is almost ready! partying_face Next, plots! An example with all the available options, rendering a data table and its associated stats, fully reactive and synchronized. Output Code

---

<div class="post-metadata">

**Author:** ![essenciary](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/essenciary/32/210469_2.png) [@essenciary](https://discourse.julialang.org/u/essenciary)\
**Post date:** [June 16, 2020, 10:48am UTC](https://discourse.julialang.org/t/front-ends-for-julia-codebases/31370/73 "2020-06-16T10:48:15Z")

</div>

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](https://quasar.dev/vue-components/bar)

[Previous page](https://discourse.julialang.org/t/front-ends-for-julia-codebases/31370.md?page=3)