Can the two language problem ever be solved for GUI programming



Yes, I agree and would like to offer Racket language as example where they achieved the following:

We’ve reimplemented the GUI layer, which meant throwing out about 200,000 lines 
of C++ code that built on Xt, Win32, and Carbon. We’ve replaced that C++ code 
with about 30,000 lines of Racket code that builds on Gtk, Win32, Cocoa, Cairo, 
and Pango. This change modernizes Racket’s graphics support while significantly 
reducing the cost of maintaining the GUI and drawing libraries.

so, wonder if there is any plan to provide something similar (aka GUI DSL) for Julia in the foreseeable future?


After the discussion here I started to work on a package that would abstract away the nasty details of opening windows, handling events and drawing things such that people could play with different designs without worrying about these issues. But I haven’t got very far with it (lack of time):


Actually, while that is in general true (meaning designing a GUI framework that works responsively - where the layout adjusts for small window size or on mobile - from scratch is certainly quite painful) with the WebIO framework one can add responsive design based CSS frameworks to a GUI designed with Interact-like code. As there has been a massive amount of work to create CSS frameworks to style and layout GUIs, I think this is a good compromise: the logic is written in Julia and the styling consists of importing a CSS stylesheet (which is how say InteractBulma was implemented).

Using JuliaGizmos packages this is already possible to a large extent, but not yet very user friendly as the tools are scattered across different packages, but you do have:

  • HTML5 based reactive widgets from Julia code
  • CSS styling and layout that accept custom user defined styles (and different themes in the future)
  • support for latex and markdown

The package Escher will be repurposed to be a meta package reexporting all the necessary tools and putting together the documentation, see this PR.

I’m working on a GUI to look at tabular data and intend to create a small spin-off package (TableInteract) where to store all the “assets” that the GUI uses, meaning widgets that are useful when working with tabular data (tools to load data / subselect it and so on). In general, the design of the new set of Interact* packages is such that it should be quite easy to create “asset store” like packages where users put composite widgets that they find useful in their job. Think of InteractBase as RecipesBase (though a bit heavier as a dependency - but this can eventually be fixed).


You are aware that this example looks similar in Gtk/Cairo?


Yes, the SDL backend uses Cairo for drawing. You could also use Gtk as a backend, although that would be a bit silly.


My point was, once you have learned the abstractions of ‘window’, ‘widget’, ‘Events’ and event loop polling or registraction of event handlers (closures) GUI programming looks surprisingly similar. If i dig out my plotting programs based on X11 i wrote 20 years ago, they might still very much look the same-

What people are looking for is something even more abstract.


The idea of that package was to provide a minimal interface to experiment with those more abstract ideas, without having to know how to open a window with SDL or GLWF. When I think of building an abstract GUI framework I think about drawing a rectangle on a window when I press a mouse button, not to allocate a surface and copy the texture onto the renderer while avoiding segmentation faults.


exactly this is abstracted by Gtk providing a cairo context for widgets or canvases and Cairo’s drawing model.

I’m not claiming that you do something wrong here, but the gain isn’t that high at the moment.


Is anyone aware of Enaml package for Python which uses Qt?


That would be great!!! See my post about Enaml. :wink:

I did attempt to try that example by using Pkg.add, but it does not work?


It’s not released, so you have to install it with Pkg.clone. You also need SDL2 (it should work on macOS but I’m not 100% on other systems). If you want to test it, please report issues on github.


Here it is. :wink: