Anyone crazy enough to develop a pure Julia GUI toolbox?

This raises a question for me:

Is it possible to build a binary that relies on an installed Julia distribution? Does it have to bundle Base and the Stdlibs with it?

Today, the answer is “no”.
Tomorrow, “were sufficient resources allocated” is the answer.
After all, relocatable code is well understood.

1 Like

This is quite the interesting discussion. To be honest what I am trying to do is move from Windows into Linux but Access does not work in Linux. I finally have a decent enough grasp on MySql to migrate the data and manage it there but I am really wanting a way to design input forms like in Access. That is all I looking for.

Indeed. Back when I was a BeOS developer (my beard is pretty grey by now) BeOS had this great thing which was called something like the “graphics server” (or some such). You interacted with it by sending messages to draw such and such thing (including things like “blit this buffer to the window”), and it was a multithreaded graphics server which was extremely responsive.

So, what if we created a protocol for a native app (different on each platform) to draw stuff in a window and send messages like “mouse over” and “mouse click”… then what if we created a protocol to send information back and forth and a language to describe what things to draw… maybe you could have the language work either locally or remotely over a network… we could have a language to separate content and styling… maybe call it Hyper Textual Markup Language (HTML) and Content Styling System (CSS)…

(in case the tongue in cheekiness doesn’t come through, I’m basically suggesting a web app)


Please don’t, and I’m 100% sure this has come up before and I’ve given exactly the same reply. Almost all of the lesser used UI framework (and even many of the popular ones) have extremely terrible input method support since most of the developers simply don’t care and don’t use any complex input method themselves. Trying to get input methods working well enough for both qt and gtk is enough work for the few of us that cares and knows how to do it. The last thing we need is a pretty looking UI framework that is non CJK-compatible.


Reference to previous discussion Chess game - #19 by yuyichao


This is a very good point. Similarly, handling BiDi languages adds a LOT of complexity:

lol. X windows. reinvented.

i too would like a stable, simple gui written in Julia.
I’m positive it can be done by leveraging some low level cross platform graphics library which at this point MUST be OpenGL based in some way, shape or form. 2D libraries are so 20th century.

i’m equally sure this is one of those things that would require so much time and effort that there’s no way to get a critical mass of people working on it.

My whole complaint about thinks like Gtk and wxWindows is that they are really difficult to get going on. I pulled up Glade one day and after several hours, gave up. i could not even figure out how to put multiple containers together to separate my elements. it was a supremely frustrating experience, and THEN there are the 50+ different fields which may describe any element. the complexity and start-up cost to do simple, but useful, things is astounding.

i solved the problem by going to CImGui which i find has the perfect balance of usefulness and complexity. But there’s one small problem, terrible documentation. if there’s not an example it’s VERY difficult to figure out how to do something, worse even than Gtk. The good news is that there are a LOT of examples.

So while i sympathize (a lot) with the OP it’s definitely a very steep hill, and i’m not sure the pay-off at the top would even be worth it, even in the long term.


Can confirm. I wrote a lot of the widgets for Makie and I spent zero time on CJK or BiDi, because I can’t speak any of those languages and don’t have time for anything but my immediate needs. It seems daunting to implement all those requirements correctly, still Makie can be useful even without such features. It’s just that one shouldn’t confuse it with a “real” GUI system or underestimate the tons of work needed to get there.

If you are just making plot there’s no problem. If you are drawing text there are likely not going to be any problem either, Unicode support is usually pretty good these days (people care enough about emoji’s to make them work everywhere). If you are taking input from a standard widget it’s also usually fine (assuming you are using a well supported toolkit behind the scene). It’s only when you decide to draw you own (text) input widget (and especially in a way that doesn’t rely on a hidden native input widget as the one handling the input) that there’s problem.

Is this what Java does with their UI toolkits?

Another thing to not forget is accessibility. I’m not sure how that is handled in something like Gtk, but in web based UIs you get a lot already built in. Doing all of that yourself is significantly complicated and involved.


to say the least :slight_smile:

At least we can try starting with student project: “reinventing the wheel” is one way to learn fundamentals. I have a strong belief that someone will do it. :smiley:

1 Like

I have seen several examples where “reinventing the wheel” ended up in “reinventing a more complicated wheel” because it’s better to understand the fundamentals before doing it. For infrastructure like GUI toolkits there is no learning by doing.

flat boards, spokes in compression, spokes in tension, balls in cups
flat spring suspension, wound spring suspensions, wishbone suspension, torsion suspension, hydraulic suspension
direct lever brakes, caliper brakes, drum brakes, disk brakes, hydraulic brakes, air brakes, electrical energy recovery brakes, torsion energy recovery brakes
solid tyres, inflated tube tyres, tubeless tyres, airless tyres


Clearly, gui’s are something even Julia is thinking about

1 Like

That vacancy is curiously thin on technical requirements. “GUI” could mean anything from desktop frameworks (Qt and friends), web front-ends (React, Vue, etc), or even terminal-based GUIs. Makes quite a bit of difference in terms of required experience. Given that cloud-based is mentioned a couple of times I would expect web front-ends is the case here.

AFAICT yes, some of them (i.e. not counting the ones that loads gtk/qt, e.g. libreoffice). And yes they do have issues with input methods. AFAICT they do implement the standard protocol, but are limited to the bad protocol on X and the worse one on wayland.

1 Like

Alternatives (or blueprints) to reinventing the wheel for publication-ready plotting GUIs:

  1. LabPlot – Scientific plotting and data analysis (
  • Support for ASCII, binary, HDF5, netCDF, FITS, ROOT, Ngspice and JSON formats with many options to control the import process
  • Tree-like organization (parent-child hierarchy) of created object, navigation is done in Project Explorer
  • Support for (i.e. embed) different open-source computer algebra systems (CAS) like Maxima, Octave, etc.

Having mentioned custom installations of backends and Julia above, in 19.08 we allow to set the custom path to the Julia interpreter similarly to how it is already possible for some other backends.
Cantor 19.08 – LabPlot (

  1. Veusz – a scientific plotting package
    Reads HDF5, written in Python → add a Julia wrapper.

[FR] Add Julia support · Issue #560 · veusz/veusz (

1 Like