Probably wouldn’t want to transmit GBs of data as JSON over HTTP but I suppose there are no hard and fast rules around that. As far as plotting lots of data points in JS, as long as you use canvas instead of SVG, you should be fine.
2 Likes
So my explorations lead me to Java where I had a lot of success but it’s just too much work right now. I realized, real fast, that all of my efforts were in wrapping code, and that really staying in Julia is the best way forward. Unfortunately, the only way to do that is via CimGui, which I’m struggling to get running and so are other’s.
So I may look into cross compatible C/C++ libraries that I can write quick hooks for to see how painful it all is. My guess is, extraordinairily painful, but you never know…
I have stupid question… Is the whole reason JS is used for front end because web browsers tend to be standardized, and the only open path for progress was either the JVM or JS? I learned about ELM which is actually really freaking cool and easy! But I don’t know if I could put it into Julia, or if that’s even possible. It seems like it could be a decent fit, but shit I don’t know anymore.
Vue.js seems great, but it seems to crazy to me to write code, that hooks into something that writes code that hooks into something that writes code that hooks into something in a web browser. There’s no way thats gonna be performant or stable, ever. Nor will it be easy to make custom widgets… So I’m spinning my gears again
I think most people like the big 3 - Angular, React, or Vue. I stumbled upon Svelte recently and it looks really interesting:
It’s quite easy to expose Julia backend as a REST service. I have tried HTTP.jl before and it works reasonably well.
3 Likes
We need a Julia based front end
4 Likes
So I just found out about GTK.jl - its pretty refined and easy to use so I plan to experiment with that a bit.
I’m working with(well not really just being a guinea pig) for getting CImGui to work on wayland OS’s. So I’m hopeful to see some progress there :).
Xiaodai - the thought definitely has crossed my mind at this point… Julia’s interop is insane, and the language is so modular, clean and fast… The problem is, that all GUI’s hook into low level things, ranging from specific OS libs, opengl, you name it, or they leverage tech. made for the early internet, ie: JVM/JS. It kind of has to be that way I guess?
No way would the web standardize on something new unless it was revolutionary and everyone wanted it. Why? because they’d want money for supporting it, or something. Meanwhile, writing hooks for all OS’s has to be extremely agonizing, and no one in their right mind wants to do that, even if the available toolset for crossplatform is a bit obtuse. It’d be a lot of work.
edit - writing a module/library that could transpile to JS seems feasible. Maybe a bit insane… Hm… Well… Hm…
1 Like
So the crew over at BinaryWrappers in Julia have solved a number of problems for us Fedora users, and probably other’s. Now CimGui works beautifully for wayland! @jpsamroo that’s a celebration right?
Also - now GTK canvas elements work for us wayland users.
Also, they made my Christmas…
3 Likes
Playing a little with GTK now. Seems pretty comfy for dev, almost has a JavaFX feel. Haven’t toyed with Glade or Builder yet, but no complaints so far. Interestingly, theres no in memory way to turn a Julia Plot to a graphical context(png/bitmap/array)? Anyways, IO on most machines is probably fast enough that this isn’t an issue, besides what can’t be done with native plots can likely be done overtop of them with canvas elements. We’ll see, gonna do some tests to see what I can do and what I can’t.
For now here’s a little snippit of loading a plot to a GTK window in a ghetto way,
using Gtk, Plots
minimaxi(x) = reduce( min, x ), reduce( max, x )
function minimaxi(x, padby)
mi,ma = minimaxi(x)
delta = (ma - mi)
return mi - (delta * padby), ma + (delta * padby)
end
random_stuff = randn(300,5) .* 10.0
a = Plots.scatter(random_stuff, fmt = :png, title = "wow",
ylim = minimaxi(random_stuff, 0.05));
#using GR
# GR.emergencyclosegks()
# env = get(ENV, "GKSwstype", "0")
# ENV["GKSwstype"] = "png"
# ENV["GKS_FILEPATH"] = ENV["GKS_FILEPATH"][1:(end-3)] * ENV["GKSwstype"]
# tmpsave = ENV["GKS_FILEPATH"]
# Plots.gr_display(a, "png")
# GR.emergencyclosegks()
# write("/tmp/wut.png", read(tmpsave, String))
#if env != "0"
# ENV["GKSwstype"] = env
#else
# pop!(ENV,"GKSwstype")
#end
#Eeek this clips plots bad!
png("/tmp/wut.png")
img = Gtk.GtkImageLeaf("/tmp/wut.png")
label = GtkLabel("Look a plot!")
g = GtkGrid()
g[1,1] = label
g[2,2] = img
w = GtkWindow(g, "Plot Viewer", 500, 500);
Gtk.showall(w)
Probably not the right suggestion in this particular case, but there is also Electron.jl. You’ll have to write your UI as a web app, though.
2 Likes
I am personally avoiding JS based UI’s for right now. I know that’s heresy and not modern, but much of the UI elements may need to be somewhat close to the metal. Probably with a lot of custom behaviour. Not saying you can’t display 10s of thousands of things via JS, nor that you can’t make anything in JS, but for my skill level it may take me a year or something to get up to speed to do that and another year to build the things I want. So I’m going to explore those only if everything else fails or becomes too cumbersome for me to make progress (like Java did).
That being said I intend for this thread to be a hodge podge of options for all things UI in Julia - not just what I want - so if you find or make anything cool (which Electron.jl is) please share!
GR (maybe not as Plots backend, but in general) should have an option to render via libcairo to an externally provided CairoContext - see in the examples https://github.com/jheinen/GR.jl/blob/master/examples/gtk_ex.jl If you build the CairoContext on top of e.g. a scripting surface you could collect render primitives and coordinates.
1 Like
Winston and Gadfly can operate directly on a cairo surface. Just search this forum for Gtk and Winston
2 Likes
I was about to add this, but then both are not backends to Plots
1 Like
I recall reading that gadfly and winston were dropped as a backend for Plots.jl, which I guess means no/minimal support as julia lang improves? I’m not scared of deprecated things, but I also don’t wanna make custom widgets and have them be super slow after time to first plot gets solved.
Winston will work in the future. I keep it going since it is used in a large in-house software of mine.
Plots.jl is only one option in julia. Certainly not the one and only. Wrapper libraries are always a compromise.
3 Likes
Good to know, maybe I will look into winston for these purposes then! It may have advantages I’m unaware of in it’s API as well.
My adventures with making GTK plots interactive can be found here: Plots.jl Plot Coordinates - An Adventure
The last Gadfly release was July 15, and latest commit to master was 3 days ago.
Makie also has a Cairo backend and is maintained. This is well beyond my expertise, but it’d be great if you could use the OpenGL backend. I’d definitely look into it if you’d like to do something fancy and interactive.
Personally, I’ve avoided using Plots.
EDIT: sdanisch is one of the main people behind both Makie and PackageCompiler, so if time-to-first plot is a concern, Makie should work well with it.
2 Likes
Interesting, maybe I misunderstood what it meant that Gadfly was deprecated as a backend for plots(Backends · Plots). Good to know about Makie. I’ve used it with Cairo before, no clue how hard it would be to hook into a UI that wasn’t JS?
Why have you been avoiding plots?
Elrod - I used to be very comfortable with OpenGL once upon a time. We’d need some convenient hooks into Julia to really get things moving. I see GTK supports GL frames, but there’s no examples with them being used for anything. Similarly, CImGUI I believe has hooks into OGL. Really half the battle for me right now is figuring out how these libraries are implemented, most of them have zero doc’s. So being able to contribute to one of them support GL hooks could be really hard… Who knows maybe it’s already in one of these packages? 
There is one aspect of CImGUI that you should be aware of. It’s a very power hungry solution. See some discussion here
1 Like
30% of your GPU just to spin up a few windows? eek. Yea I am going to stick with Gtk first then. But, I intend to experiment with it nevertheless. The built in plot widgets are an attractive solution to scientific applications. At the cost of some GPU? Might be a fair trade 
GTK
So I was able to get GTK running with Cairo in Julia 1.3 - no hitches whatsoever. For me, this is the solution I was looking for. Why?
- It’s platform agnostic
- It’s easy to write event listeners
- Custom widgets can be made with GtkCanvas, and a little elbow grease
- It’s fast(at least fast enough for me not to notice any slowness). Also, it precompiles quickly enough.
So what’s the deal? If you read through the garbled mess I wrote in this thread you’ll see I started via writing hooks between the JVM and Julia to leverage JavaFx’s tooling. What I found was that writing hooks to Julia for close interop was really painful, even by cheating and directly calling background Julia processes there was too much developer overhead for me to meet the goals I want to meet without a team of people.
By making the same custom, and boiler plater UI elements from JavaFX into Gtk I noticed some things… The custom interactive plot solution I wrote in Gtk worked noticibly faster then the baseline JavaFX linechart widget. Handling the collections in Java, despite it being a language specialty, was laggy for largish data because of how I designed it, and how LineCharts.java works.
By making the same custom menu widget I want in the tool I’m working on(yes the menu is actually integral to the tool itself - I won’t explain), I reduced my java code from ~5 class files and 600 lines of effort(very little boiler plate because this was a prototype effort) to 1 file, with recyclable methods (useful for both widgets) in <180 lines of code.
So, development is less painful, more generic, in one language(okay two because GTK is C++, but its not C++ I have to write!), and more efficient.
My current conclusion is that, there’s no reason to really leave Gtk right now. I haven’t run into any dead ends that made me turn around yet. Highly reccommend trying the latest version Gtk.jl out if you haven’t already and need a desktoppy UI that isn’t painful.
For WebUI’s anyones choice or guess is better then my own.
2 Likes