# Anyone crazy enough to develop a pure Julia GUI toolbox?

**URL:** <https://discourse.julialang.org/t/anyone-crazy-enough-to-develop-a-pure-julia-gui-toolbox/74002>\
**Category:** Visualization\
**Tags:** package, gui\
**Created:** [January 3, 2022, 9:20pm UTC](https://discourse.julialang.org/t/anyone-crazy-enough-to-develop-a-pure-julia-gui-toolbox/74002 "2022-01-03T21:20:04Z")\
**Posts on this page:** 20\
**Page:** 4

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [January 5, 2022, 5:41pm UTC](https://discourse.julialang.org/t/anyone-crazy-enough-to-develop-a-pure-julia-gui-toolbox/74002/62 "2022-01-05T17:41:30Z")

</div>

Yea, I think something like GtkReactive.jl

[https://juliagizmos.github.io/GtkReactive.jl/stable/drawing.html](https://juliagizmos.github.io/GtkReactive.jl/stable/drawing.html)

… or its potential successor in GtkObservables.jl as mentioned above seems like it is moving in the right direction.

[https://juliagizmos.github.io/GtkObservables.jl/dev/controls/](https://juliagizmos.github.io/GtkObservables.jl/dev/controls/)

Using GTK as a basis seems like the path of least resistance since it uses C rather than C++ and is thus easier to call directly from Julia.

Another alternative is the QT based QML.jl  
[https://github.com/barche/QML.jl](https://github.com/barche/QML.jl)

That said writing the equivalent of Java’s AWT, Swing, or the Android UI does seem unnecessary given the availability of the above.

---

<div class="post-metadata">

**Author:** ![sashmit](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sashmit/32/18791_2.png) [@sashmit](https://discourse.julialang.org/u/sashmit)\
**Post date:** [January 5, 2022, 5:47pm UTC](https://discourse.julialang.org/t/anyone-crazy-enough-to-develop-a-pure-julia-gui-toolbox/74002/63 "2022-01-05T17:47:52Z")

</div>

Personally, if you are interacting with a lot of data points, I would look into a immediate mode GUI, of which imgui is the most famous.

They are very underrated!

And much easier to use than something like gtk, imho.

See what imgui can do:  
[https://github.com/ocornut/imgui/issues/2265](https://github.com/ocornut/imgui/issues/2265)

and a nice Julia wrapper:  
[https://github.com/Gnimuc/CImGui.jl](https://github.com/Gnimuc/CImGui.jl)

imgui also compiles just fine to webassembly.

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [January 5, 2022, 5:47pm UTC](https://discourse.julialang.org/t/anyone-crazy-enough-to-develop-a-pure-julia-gui-toolbox/74002/64 "2022-01-05T17:47:55Z")

</div>

Well, I would not say it is unnecessary… GTK has a lot of disadvantages, Glade is terrible and you end up reading C library documentation…  
QML is broken on 1.7…

---

<div class="post-metadata">

**Author:** ![joa-quim](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/joa-quim/32/227_2.png) [@joa-quim](https://discourse.julialang.org/u/joa-quim)\
**Post date:** [January 5, 2022, 6:11pm UTC](https://discourse.julialang.org/t/anyone-crazy-enough-to-develop-a-pure-julia-gui-toolbox/74002/65 "2022-01-05T18:11:48Z")

</div>

`imgui` has a huge drawback. It’s barely usable from laptops because it puts the gpu running at 100% **all** the time. I don’t want mine to melt that way.

As I referred before in other posts about this. My hopes were in `libui` and even made a [wrapper](https://github.com/joa-quim/Libui.jl) once but the `libui` project looks dead, though there are still people trying to resurrect it.

---

<div class="post-metadata">

**Author:** ![Henrique\_Becker](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/henrique_becker/32/15443_2.png) [@Henrique\_Becker](https://discourse.julialang.org/u/Henrique_Becker)\
**Post date:** [January 5, 2022, 6:37pm UTC](https://discourse.julialang.org/t/anyone-crazy-enough-to-develop-a-pure-julia-gui-toolbox/74002/66 "2022-01-05T18:37:35Z")

</div>

> [@ufechner7](#):
>
> 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…

> [@jonathanBieler](#):
>
> 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 […] 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.

Okay, but how much is necessary to rewrite to achieve that? Could it be in a package on top of `GTK.jl` or not? The `GTK.jl` design seems the same of many solver wrappers (Gurobi.jl, CPLEX.jl, GLPK.jl, Xpress.jl) that is: just wrap every function automatically and point to the original documentation (often C/C++). JuMP then enters as a layer above all of them which allows writing mathematical models without worrying about the specific solver and its peculiarities. The problem here is that, as there is no layer above `GTK.jl`, it is not worth converting all documentation with small changes to Julia, nor the code follows what would be Julia design patterns. A package above `GTK.jl` (instead of replacing `GTK.jl`) could take care of these problems.

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [January 5, 2022, 7:18pm UTC](https://discourse.julialang.org/t/anyone-crazy-enough-to-develop-a-pure-julia-gui-toolbox/74002/67 "2022-01-05T19:18:55Z")

</div>

> [@Henrique\_Becker](#):
>
> A package above `GTK.jl` (instead of replacing `GTK.jl` ) could take care of these problems.

GtkReactive is a package that sits above GTK.jl

[https://juliagizmos.github.io/GtkReactive.jl/stable/controls.html](https://juliagizmos.github.io/GtkReactive.jl/stable/controls.html)

GtkObservables is a further iteration on this taking advantage of Observables.jl:

[https://juliagizmos.github.io/Observables.jl/latest/](https://juliagizmos.github.io/Observables.jl/latest/)

Importantly, Observables.jl is generic. You could combine with another graphics framework to enable a similar signals-and-slots pattern.

---

<div class="post-metadata">

**Author:** ![SergeantMike67](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sergeantmike67/32/25103_2.png) [@SergeantMike67](https://discourse.julialang.org/u/SergeantMike67)\
**Post date:** [January 5, 2022, 7:19pm UTC](https://discourse.julialang.org/t/anyone-crazy-enough-to-develop-a-pure-julia-gui-toolbox/74002/68 "2022-01-05T19:19:00Z")

</div>

This is an unnecessary splitting of hairs. I think it was very obvious what I was talking about with the OP given the current state of the Julian infrastructure. I don’t believe that the creators of GTK or QML were asked to parse out their use of words in such a manner. I guess my mistake was not including the phrase “native Julia at a level most reasonable developers can use without having to re-write the entire operating system in Julia.” I’ll try to be more specific in the future

---

<div class="post-metadata">

**Author:** ![jzr](https://avatars.discourse-cdn.com/v4/letter/j/eb9ed0/32.png) [@jzr](https://discourse.julialang.org/u/jzr)\
**Post date:** [January 5, 2022, 7:33pm UTC](https://discourse.julialang.org/t/anyone-crazy-enough-to-develop-a-pure-julia-gui-toolbox/74002/69 "2022-01-05T19:33:06Z")

</div>

Another option I haven’t seen mentioned is making a TUI toolkit. Here are some from other languages

[https://github.com/fdehau/tui-rs](https://github.com/fdehau/tui-rs)

[https://github.com/Textualize/textual](https://github.com/Textualize/textual)

---

<div class="post-metadata">

**Author:** ![jonathanBieler](https://avatars.discourse-cdn.com/v4/letter/j/82dd89/32.png) [@jonathanBieler](https://discourse.julialang.org/u/jonathanBieler)\
**Post date:** [January 5, 2022, 7:34pm UTC](https://discourse.julialang.org/t/anyone-crazy-enough-to-develop-a-pure-julia-gui-toolbox/74002/70 "2022-01-05T19:34:08Z")

</div>

Gtk.jl actually does abstract quite a bit from GTK already but it’s true it could be improved to hide the library more. That said I think it’s very hard to get away from GTK logic and design without encountering some serious issues. For example if a user wants to update part of the GUI at regular intervals, it might not be safe to do it from Julia’s side, because you can invalidate GTK objects and that will lead to random segfaults (Gtk apps can be a nightmare to debug). Instead the user should add a callback to GTK’s main loop, so it’s hard to hide these concepts completely.

Working on Gtk.jl is also difficult because you need to have a good understanding of both GTK and Julia’s internals. A lot of GTK designs are also linked to C limitations (GTK has it’s own pseudo object system, memory management,…) and presumably one could do something better in 2022.

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [January 5, 2022, 8:12pm UTC](https://discourse.julialang.org/t/anyone-crazy-enough-to-develop-a-pure-julia-gui-toolbox/74002/71 "2022-01-05T20:12:53Z")

</div>

Looking more into Wayland, it does look like there might be decent cross platform support in the future beyond the native Linux support.

macOS: [https://github.com/owl-compositor/owl](https://github.com/owl-compositor/owl)  
Windows Subsystem for Linux: [Run Linux GUI apps with WSL | Microsoft Docs](https://docs.microsoft.com/en-us/windows/wsl/tutorials/gui-apps)

While someone may still need to understand C to do move this forward via libwayland, it does seem plausible. Eventually, it is also may be possible to implement the Wayland wire protocol directly in Julia without needing to depend on libwayland C library.

[https://wayland-book.com/](https://wayland-book.com/)  
[https://github.com/emersion/hello-wayland](https://github.com/emersion/hello-wayland)

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [January 5, 2022, 9:27pm UTC](https://discourse.julialang.org/t/anyone-crazy-enough-to-develop-a-pure-julia-gui-toolbox/74002/72 "2022-01-05T21:27:48Z")

</div>

@logankilpatrick put together a nice overview here about existing frameworks:

> **[6 Julia Frameworks to Create Desktop GUI’s 🖥 and Web Apps 🕸](https://towardsdatascience.com/6-julia-frameworks-to-create-desktop-guis-and-web-apps-9ae1a941f115)**
>
> You could build beautiful apps purely in Julia.

---

<div class="post-metadata">

**Author:** ![SergeantMike67](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sergeantmike67/32/25103_2.png) [@SergeantMike67](https://discourse.julialang.org/u/SergeantMike67)\
**Post date:** [January 5, 2022, 9:43pm UTC](https://discourse.julialang.org/t/anyone-crazy-enough-to-develop-a-pure-julia-gui-toolbox/74002/73 "2022-01-05T21:43:03Z")

</div>

@caleb-allen I think you are getting the gist of the original idea along with @jonathanBieler and @ufechner7. There seems to be a lot of folks on this thread that like to look at a problem and see all the things that can go wrong and say it can’t be done or shouldn’t be done. If you or anyone is willing to risk abject failure and embarrassment tilting at this windmill and possibly come up with something useful, elegant and Julia based towards this end, I am willing to set up a Git Repositorynot that I have a damned clue on how to do that but there are tutorials, and start dedicating time to it. If not then I am perfectly willing to table this discussion until a later release.

---

<div class="post-metadata">

**Author:** ![Henrique\_Becker](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/henrique_becker/32/15443_2.png) [@Henrique\_Becker](https://discourse.julialang.org/u/Henrique_Becker)\
**Post date:** [January 5, 2022, 10:23pm UTC](https://discourse.julialang.org/t/anyone-crazy-enough-to-develop-a-pure-julia-gui-toolbox/74002/74 "2022-01-05T22:23:30Z")

</div>

> [@SergeantMike67](#):
>
> I guess my mistake was not including the phrase “native Julia at a level most reasonable developers can use without having to re-write the entire operating system in Julia.”

Okay, and what level is that? This includes rewriting `GTK.jl` or not? Or it will build above another library like QT? It will support X11, Wayland, Windows, or focus on just one of these? These are things that need to be defined before starting the project.

---

<div class="post-metadata">

**Author:** ![sashmit](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sashmit/32/18791_2.png) [@sashmit](https://discourse.julialang.org/u/sashmit)\
**Post date:** [January 5, 2022, 10:43pm UTC](https://discourse.julialang.org/t/anyone-crazy-enough-to-develop-a-pure-julia-gui-toolbox/74002/75 "2022-01-05T22:43:07Z")

</div>

another option might be to wrap one of the various new UI toolkits for Rust:  
[https://www.areweguiyet.com/](https://www.areweguiyet.com/)

personally, I’m skeptical of the viability of user interface-toolkits that don’t target the browser (or adjacent technologies) for at least one of the backends.

---

<div class="post-metadata">

**Author:** ![jzr](https://avatars.discourse-cdn.com/v4/letter/j/eb9ed0/32.png) [@jzr](https://discourse.julialang.org/u/jzr)\
**Post date:** [January 5, 2022, 10:53pm UTC](https://discourse.julialang.org/t/anyone-crazy-enough-to-develop-a-pure-julia-gui-toolbox/74002/76 "2022-01-05T22:53:19Z")

</div>

It would be cool to have Julia bindings to Rust’s gui libraries. Possibly even cooler to port them to pure Julia, but that would take a _lot_ longer.

Neither of these is yet stable but both quite interesting:

[https://github.com/linebender/druid](https://github.com/linebender/druid)

[https://github.com/iced-rs/iced](https://github.com/iced-rs/iced)

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [January 6, 2022, 12:22am UTC](https://discourse.julialang.org/t/anyone-crazy-enough-to-develop-a-pure-julia-gui-toolbox/74002/77 "2022-01-06T00:22:17Z")

</div>

I would be interested in a GUI toolkit that does not build on top of GTK (problematic programming model) and not on top of QT (license issues, large, C++ not so easy to integrate with Julia).

I like the Rust libraries, that were suggested, but also [https://github.com/MasFlam/AttoUI?ref=bestofcpp.com](https://github.com/MasFlam/AttoUI?ref=bestofcpp.com)

Not so sure if extending Makie.jl would also be an option…

---

<div class="post-metadata">

**Author:** ![liuyxpp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/liuyxpp/32/9870_2.png) [@liuyxpp](https://discourse.julialang.org/u/liuyxpp)\
**Post date:** [January 6, 2022, 1:08am UTC](https://discourse.julialang.org/t/anyone-crazy-enough-to-develop-a-pure-julia-gui-toolbox/74002/78 "2022-01-06T01:08:13Z")

</div>

It sounds a web-based solution will perfectly fit your requirement. I used to write a Flask-based app (Python) to handle my simulation data. I believe in Julia domain maybe Genie or Dash will do the job well. It works perfectly for such tasks.

---

<div class="post-metadata">

**Author:** ![lawless-m](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lawless-m/32/30869_2.png) [@lawless-m](https://discourse.julialang.org/u/lawless-m)\
**Post date:** [January 6, 2022, 8:25am UTC](https://discourse.julialang.org/t/anyone-crazy-enough-to-develop-a-pure-julia-gui-toolbox/74002/89 "2022-01-06T08:25:44Z")

</div>

Press “OK” then wait for “OK” codepath to compile, hourglass pops up.

Press “Cancel” wait for “Cancel” codepath to compile, hourglass pops up.

---

<div class="post-metadata">

**Author:** ![mhinsch](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mhinsch/32/26676_2.png) [@mhinsch](https://discourse.julialang.org/u/mhinsch)\
**Post date:** [January 6, 2022, 2:30pm UTC](https://discourse.julialang.org/t/anyone-crazy-enough-to-develop-a-pure-julia-gui-toolbox/74002/92 "2022-01-06T14:30:01Z")

</div>

> [@lawless-m](#):
>
> Press “OK” then wait for “OK” codepath to compile, hourglass pops up.
> 
> Press “Cancel” wait for “Cancel” codepath to compile, hourglass pops up.

Exactly. Without some bit of pre-compiled code doing the heavy lifting a pure Julia GUI would be a nightmare to use. Which means either good binary caching in Julia itself or system images containing the GUI code. Or, of course, just use a compiled library such as GTK as a backend.  
I love Julia, but honestly at this stage I think it’s just not the right language for GUI development (or similar things, such as games).

---

<div class="post-metadata">

**Author:** ![jonathanBieler](https://avatars.discourse-cdn.com/v4/letter/j/82dd89/32.png) [@jonathanBieler](https://discourse.julialang.org/u/jonathanBieler)\
**Post date:** [January 6, 2022, 3:18pm UTC](https://discourse.julialang.org/t/anyone-crazy-enough-to-develop-a-pure-julia-gui-toolbox/74002/93 "2022-01-06T15:18:49Z")

</div>

This actually happens in Gtk.jl (presumably because callbacks & wrapping code need to be compiled), it doesn’t seem much better than in Makie. I think all this GUI talk needs to assume we’ll have good binary caching at some point.

[Previous page](https://discourse.julialang.org/t/anyone-crazy-enough-to-develop-a-pure-julia-gui-toolbox/74002.md?page=3)

[Next page](https://discourse.julialang.org/t/anyone-crazy-enough-to-develop-a-pure-julia-gui-toolbox/74002.md?page=5)