Can the two language problem ever be solved for GUI programming

[gour]

@StefanKarpinski

In short, it doesn’t seem like there’s any fundamental reason why Julia couldn’t solve the two language problem in graphics with some more time and effort.

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?

[jonathanBieler]

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

https://github.com/jonathanBieler/GUIFrameworkPlayground.jl/blob/master/examples/example01.jl

[piever]

@Tamas_Papp

If one is willing to use a Jupyter notebook,

JuliaGizmos/Interact.jl

would work for that.

Otherwise, I have learned to be cautious of using “simple” to describe a GUI. They look simple to the user (that’s the point), but the programmer has to deal with a zillion minor problems to make that happen: what happens when the window is resized, how do units map to the screen (HiDPI taught people who thought they could use pixels a painful lesson), does it work OK cross-platform, etc.

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

@Steven_Sagaert

What we need is the equivalent of Shiny for quickly building simple web GUIs/web apps around data visualization, querying the data/results or as a simple interactive report (knitr plays an important role there too and it’s integration with Shiny).

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

[lobingera]

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

[jonathanBieler]

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

[lobingera]

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.

[jonathanBieler]

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.

[lobingera]

@jonathanBieler

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.

[gour]

@jonathanBieler

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.

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

[gour]

@jonathanBieler

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.

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

But I haven’t got very far with it (lack of time):

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

[jonathanBieler]

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.

[gour]

@jonathanBieler

If you want to test it, please report issues on github.

Here it is.

[emmettgb]

Hmmm… Aside from UI and stuff, I think Godot is cool in general… Perhaps I could get to working on something… The biggest problem I think that we would face is likely typing, as you mentioned… We can only use inheritance from one supertype per-type, and while we can do this heirarchically, it won’t mean the inheritance of anything except methods.
Curious… If you were to see this package come into fruition, would you rather it use the object-oriented paradigm so the calls are identical, or would you rather use functional calls and make a big leap from GDscript and C++?