I see there are GTK bindings for Julia language for those desiring to write desktop GUI app. However I’m evaluating whether Julia can replace Python as suitable language for writing GUI apps which has things like PyQt which is probably better option than GTK.
There is Cxx project providing C++ interface, but I’m simply not aware of any Qt bindings for Julia?
Another (potential) possibility it to use Julia for the ‘business logic’ and combine it with PyQt by using PyCall, but no idea how smooth it can be?
The last option is, of course, using some kind of HTML/JS technology which I really do not like and would prefer to stay free from fiddling with JS crap, but if you have some decent option?
Language-wise, there is no question that Julia is much better alternative over Python, but wonder if it can be advantageous for writing (desktop) GUI apps as well or that is simply not language’s niche at the moment?
Work on QML.jl is in progress. I intend to finish work on the ListModel and work towards a release then. I think that for simple GUI work it’s already quite usable in its current form. At the latest master you will need to do a checkout on CxxWrap.jl to use it.
Of course Julia isn’t yet as mature as other languages in almost any sector (it grows up fast though), so any option comes with some integration challenges. But developing GUI apps in Julia is fully possible. I am one of those who really do not like JS. However, the option to combine HTML + a little JS (mostly AJAX) + a lot Julia, has too many advantages to bypass in modern browser-dominated world, so I’ve gone myself with that last option.
You don’t have to write HTML and JS to take advantage of web tech. There is Escher and Rutherford available. Escher is more abstract in that it hides many of the idiosyncrasies of HTML. While Rutherford looks a lot like HTML and CSS still.
There is also Blink which provides a JS compiler so you can while JS with a more Julia like syntax.
Both Escher and Rutherford are designed for apps to be written in a functional style. Escher uses signals FRP style and Rutherford uses one big immutable data structure. And I guess Blink assumes your app will be written imperatively.
Edit: I should note that I rarely do this in practice. Most of the time I’m able to split things up so that I have Julia code that pulls data, does a ton of processing, then updates a database, and then a node-based API that sits on top of that database, and an Angular 1/2 web app that consumes the data from the API. Depending on what level of interactivity you need, this may not work.
I’ve used the HttpServer package to “talk” to the browser through the HTTP protocol, while the rest is custom code:
The back-end of the app written in Julia and operating with high-level types (most of the code goes here and can be coded freely to the programmer’s taste).
The front-end of the app written in Julia to resolve HTTP requests into high-level calls to the app’s back-end, and then form the app’s return into HTTP responses (this is easier than it sounds, thanks to the HttpServer package, still it’s not trivial).
An HTML generator written in Julia to fill an IOBuffer with the app’s return’s high-level types turned into HTML tags (this is plain dumping).
A small client-side file written in JS to translate events into AJAX requests and update the proper fields of the HTML DOM with the server’s response (this is easier than it sounds, thanks to modern browsers, still JS makes it non-trivial).
Why not simply give Gtk.jl a try? It is certainly the most mature package for writing GUI applications and in combination with Glade its a pretty modern approach to write UI apps. I have build a pretty large app with Gtk.jl and until now are more than satisfied.
FWIW I really appreciate the design of Gtk.jl and would like to use it.
But my problem with Gtk is that it really is very rough on Windows (and also Mac), unless I have missed something. And this is made even worse on very high resolution displays. Qt on the other hand does much better on both platforms. This is not a minor issue, ugly GUIs really do put people off in a slightly irrational way (the functionality might be perfect).
I also use GNOME so I like Gtk’s look’n’feel - the only consideration is that I?m repeatedly told that it looks like crap on Mac OS & Windows…I do not run Windows any longer, even under Virtualbox since XP was the last license I had and never had access to the Mac OS…
I use Gtk.jl on all three platforms. I can not confirm that there are issues on Windows. It simply works and looks ok.
OS X has in my experience some more glitches but in principle works as well.
The point is that it does not make too much sense discussing various UI frameworks in isolation here. The question is how they fit to Julia. In Gtk fits very very well to Julia since it is a C library and @jameson did an awesome job to integrate Gtk with Julia. Most types are automatically handled which makes programming with Gtk.jl a pleasant experience.
This does not mean that everything is perfect: There are missing peaces, the project lacks developers, documentation is not perfect. But nevertheless if someone wants to do serious UI development it is from my perspective the best option.
I also use GNOME so I like Gtk’s look’n’feel - the only consideration is that I?m repeatedly told that it looks like crap on Mac OS & Windows…I do not run Windows any longer, even under Virtualbox since XP was the last license I had and never had access to the Mac OS…
Are you concerned about the cross platform capabilities as your project should be usable for other users?
If something looks like crap is pretty subjective and maybe you should form your own opinion on the look and feel. In practice it is much more important that a UI is usable instead that it looks good.
As a general observation on this issue, I think it’s pretty frustrating that we don’t have a good answer to this, but I think we’re not alone – the GUI toolkit space seems to be long on options and short on satisfaction. It seems that you can have two of the following three:
Cross-platform.
Really good native look.
General: can build any kind of GUI.
Single-platform are often very good and provided by the platform vendor – these are 2 & 3. Most other toolkits are cross-platform but leave much to be desired in aesthetics – i.e. 1 & 3. Many people have tried, but it seems almost impossible to write generic cross-platform GUI code and have it look really good on all platforms. But I have to wonder if there isn’t a space for 1 & 2 – i.e. a limited-purpose cross-platform toolkit with very nice, largely automatic, native aesthetics. A lot of scientific applications have pretty limited, simple GUI requirements, and it would be nice if they were cross-platform and looked really good, as compared to the notoriously bad looks of some common open source GUI toolkits. Part of the problem seems to be automatic widget layout, which is a notoriously hard problem, but one which Julia is well-positioned to address since we’ve got JuMP
Not sure if I fully agree. In my experience scientific apps are actually pushing UIs to the limit and therefore need the flexibility to do customization. And at that point you are lost if your toolkit is just a large wrapper that does not give you a handle to the low level part.
Just as an example why I am so excited about Gtk.jl: If you render an image with Gtk, you actually just draw on a native Cairo canvas. And with Cairo.jl being a very mature package this is really just fun to do. You can for instance natively embed Winston into any Gtk app without any issue.
I have considered other alternatives but the power that I get from Gtk + Cairo + Winston is pretty sophisticated.
One other thing is that nowadays one actually does not want to code the layout of an application. Layout is done in a declarative way using e.g. xml in combination with an UI designer. Thus, when considering UI toolkits it essential that this is provided.
Having a canvas is actually pretty simple – it’s just an area where the program is totally in charge of the pixels. The stuff that’s hard for the GUI toolkit is the layout of text and buttons around it, which is where I think that scientific apps have relatively limited requirements, compared to, e.g. a word processor or spreadsheet app.
Frankly speaking I’m mostly concerned to make the project to work on my native (Linux) platform and having cross-platform app is just a convenient add-on. I’m thinking about open-source app, but aware that it’s not that everyone is using Linux on the desktop.
However, I am simply not attracted to pursue web-technology in order to make it cross-platform.
Finally, PyQt is a valid proof that it’s possible to have great GUI by not using C(++)…
