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