I would love to have native julia widgets, but not at that level to do it. I’ve made some gui apps with gtk.jl and made a guide - Julia: simple GUI apps with Gtk.jl – kodintent
Gtk.jl is stable but a bit crappy and seems in maintenance mode. Maybe it could do the form you want, I think.
I just started looking at qml.jl today, as I want progress feedback with some apps.
I think most people using julia have no desire for a gui.
1 Like
Is there a poll on this? If not, could someone build one?
4 Likes
This is not a question about majorities, in my opinion.
It’s about the generality of Julia as a language. For this currently two features are missing, only one is really missing: building stand alone applications without the need for the Julia compiler environment as part of it.
For some people, including me, an easy to use, state of the art, platform independent, GUI framework is missing too. (Well, I can live with what is currently available regarding GUI, but none is easy, only few are state-of-the-art 
)
Having both issues fixed would bring Julia on the next level.
9 Likes
I found a way to get that stand alone app experience with gtk.jl, gui window only from single app menu click, no repl or terminal, but it’s just with limited capability.
I used to make convenience apps with uwp c# before escaping mswin, and it would be nice to have that kind of functionality with julia because learning c or c++ is absolutely never going to happen.
But it’s still with complete julia compiler. If you try to bundle it into something someone else can install without knowing about Julia you will see, that it will be quite large (>200MB) even for the smallest thinkable GUI/Julia app. Even PackageCompiler doesn’t solve this currently Julia inherent issue, because it is (as of now) a direct consequence of dynamic dispatch.
I would like to have a way to get rid of the dynamic part, because I know that no unknown types are possible in my app. E.g. when all functions are fully typed (concrete types) in parameters and return values, there should be no dynamic dispatch anymore.
(off topic here, if this becomes a separate discussion we let the moderators move it to another one)
Yes, as a portable cross-os package, it’s messy as. That issue is distant from me.
My experience goal is to use one click open gui convenience apps that behave like os native apps and are easy to make. I reliably have that after some initial setup. That’s nice enough, except for the limited capability. Julia is so easy to dev in, so I want more capability available within that easy syntax.
2 Likes
Exactly this.
This raises a question for me:
Is it possible to build a binary that relies on an installed Julia distribution? Does it have to bundle Base and the Stdlibs with it?
Today, the answer is “no”.
Tomorrow, “were sufficient resources allocated” is the answer.
After all, relocatable code is well understood.
1 Like
This is quite the interesting discussion. To be honest what I am trying to do is move from Windows into Linux but Access does not work in Linux. I finally have a decent enough grasp on MySql to migrate the data and manage it there but I am really wanting a way to design input forms like in Access. That is all I looking for.
Indeed. Back when I was a BeOS developer (my beard is pretty grey by now) BeOS had this great thing which was called something like the “graphics server” (or some such). You interacted with it by sending messages to draw such and such thing (including things like “blit this buffer to the window”), and it was a multithreaded graphics server which was extremely responsive.
So, what if we created a protocol for a native app (different on each platform) to draw stuff in a window and send messages like “mouse over” and “mouse click”… then what if we created a protocol to send information back and forth and a language to describe what things to draw… maybe you could have the language work either locally or remotely over a network… we could have a language to separate content and styling… maybe call it Hyper Textual Markup Language (HTML) and Content Styling System (CSS)…
(in case the tongue in cheekiness doesn’t come through, I’m basically suggesting a web app)
3 Likes
Please don’t, and I’m 100% sure this has come up before and I’ve given exactly the same reply. Almost all of the lesser used UI framework (and even many of the popular ones) have extremely terrible input method support since most of the developers simply don’t care and don’t use any complex input method themselves. Trying to get input methods working well enough for both qt and gtk is enough work for the few of us that cares and knows how to do it. The last thing we need is a pretty looking UI framework that is non CJK-compatible.
3 Likes
Reference to previous discussion Chess game - #19 by yuyichao
2 Likes
This is a very good point. Similarly, handling BiDi languages adds a LOT of complexity:
http://www.unicode.org/reports/tr9/
lol. X windows. reinvented.
i too would like a stable, simple gui written in Julia.
I’m positive it can be done by leveraging some low level cross platform graphics library which at this point MUST be OpenGL based in some way, shape or form. 2D libraries are so 20th century.
i’m equally sure this is one of those things that would require so much time and effort that there’s no way to get a critical mass of people working on it.
My whole complaint about thinks like Gtk and wxWindows is that they are really difficult to get going on. I pulled up Glade one day and after several hours, gave up. i could not even figure out how to put multiple containers together to separate my elements. it was a supremely frustrating experience, and THEN there are the 50+ different fields which may describe any element. the complexity and start-up cost to do simple, but useful, things is astounding.
i solved the problem by going to CImGui which i find has the perfect balance of usefulness and complexity. But there’s one small problem, terrible documentation. if there’s not an example it’s VERY difficult to figure out how to do something, worse even than Gtk. The good news is that there are a LOT of examples.
So while i sympathize (a lot) with the OP it’s definitely a very steep hill, and i’m not sure the pay-off at the top would even be worth it, even in the long term.
3 Likes
Can confirm. I wrote a lot of the widgets for Makie and I spent zero time on CJK or BiDi, because I can’t speak any of those languages and don’t have time for anything but my immediate needs. It seems daunting to implement all those requirements correctly, still Makie can be useful even without such features. It’s just that one shouldn’t confuse it with a “real” GUI system or underestimate the tons of work needed to get there.
If you are just making plot there’s no problem. If you are drawing text there are likely not going to be any problem either, Unicode support is usually pretty good these days (people care enough about emoji’s to make them work everywhere). If you are taking input from a standard widget it’s also usually fine (assuming you are using a well supported toolkit behind the scene). It’s only when you decide to draw you own (text) input widget (and especially in a way that doesn’t rely on a hidden native input widget as the one handling the input) that there’s problem.
Is this what Java does with their UI toolkits?
Another thing to not forget is accessibility. I’m not sure how that is handled in something like Gtk, but in web based UIs you get a lot already built in. Doing all of that yourself is significantly complicated and involved.
8 Likes
to say the least 