How to create standalone applications for Windows with a [G]UI in Julia 1.11 or 1.12

General Usage
21

I am surprised. I mean, go to any research lab of a company of your choice and look how they work:

  1. there are lab workers handling different machines, perform measurements etc.
  2. there are scientists who take the data to develop new things
  3. there are scientists that have to work parallel to the running production, to do the quality assurance and deal with guarantee cases.

Person class 1 need software that “just works”. Most of them have never seen any program code in their life. They need software with a menu in which they can select the tasks they have to perform (loading/saving a file, creating a plot etc.)

Person class 2 might be interested in the source code, adapt it, write own scripts and libraries. But not at a daily basis. If you develop e.g. a better process for a chemical reaction, you need to evaluate sensor data like temperature. You then just need software that does this job for you and also the job of automatically plotting the data, analyzing it using a pre-trained neuronal network. Or you want to teach a new neuronal network with your sensor data. Then you also need a proper UI that guides you through this.

Person class 3 also need software that “just works”. They have no time to work with program code. They need to perform measurements, generate reports etc.

Julia aims to be a programming language for scientific tasks. So it should also focus on how development and science is done in practice outside of universities.

Maybe I misunderstood you, but saying that serving many thousand lab workers all over the world across all kinds of science is “not a typical use case” sounds arrogant to me.

6 Likes
22

To the limited extend that I have insight into industry research labs (IBM, Google, various quantum-computing startups), they don’t seem that fundamentally different from a university research lab environment.

You can certainly write software in Julia that “just works” and that does not expose source code to the user. But especially for a lab worker inside a research lab, I don’t see that they wouldn’t have staff to set up their lab computer with the Julia environment (or whatever else is required) to run the UI that they need to operate the experiment.

I was under the impression that you were more talking about shipping commercial software to lab workers of an outside organization, where smooth deployment is much more of a difficult concern.

It’s not intended as a value judgement, merely as a description of the state of things. I would be more than happy with developments in Julia that make it easier to ship small binaries, or even native GUI applications. But I’m pretty sure it’s not “typical” for what most current Julia users do.

Like I said, I don’t think what you’re asking for is unreasonable, but it’s not something that Julia currently provides a great solution for.

3 Likes
23

Hey @uwestoehr, I get that you’re frustrated. If I may intervene here, I’m quite certain that @goerz is not saying that distributing binaries and GUIs is an uncommon use-case. It is, however, not yet a common use-case for Julia. It’s not arrogance about the state of the world at large, it’s setting expectations for what Julia can do.

IMO, even when Julia can easily and robustly generate small binaries, it still will probably be easiest to use C#/.NET/WPF or Javascript/HTML/Electron to create the GUI front-ends that can talk to a Julia dll/so/dylib — especially because LLMs are quite good at generating bog-standard GUIs with bog-standard tooling. GUIs are all about library APIs. And it will always be easiest to generate them using the most common native language(s) for the target platform(s).

10 Likes
24

Yes, that’s absolutely right :slight_smile:

1 Like
26

I fully agree and this is also the way I want to go. We have existing programs, most with Qt some with Lazarus. So a DLL is the right solution for our use case.

28

the snack bar is way better tho

1 Like
36

Wanted to jump back in with a few comments on this thread, starting with, I’m really glad we’re having this conversation, given the diversity of perspectives on what Julia is and/or should be here. I’m especially interested in broadening the base of users (as is being discussed in the parallel thread), and the collection of compilation/deployment/GUIs recur in those kinds of discussions. I’m pursuing some nascent work in this general area, so this thread and others like it are enlightening.

These are the people I generally support, so I fully agree here. The use case, as I refer to it, is building internal scientific, engineering, and analysis (SEA) tools for end users. (Note that this is roughly equivalent to internal tools development, though those tools generally target business/database users and are web-based. My users are technical analysts doing desktop modeling and simulation, but they typically aren’t writing low-level code. I’ve seen efforts to provide solutions in Python, but the bolt-on GUIs and deployment, not to mention performance, are problematic. I can easily see an opportunity for Julia here if we can address the issues that @uwestoehr is encountering.

GUIs… the current state of this for cross-platform development isn’t great. There was yet another timely piece today speaking to the difficult landscape here. (BTW, I’m not advocating for X-Windows and Lisp…). In this thread alone, we’ve heard about GTK, IMGUI, QT, and I’ve looked at pretty much everything else on the list at one time or another. My takeaways for Julia and GUIs for SEA are:

  • There are probably a limited set of higher-level “widgets” needed for this work; providing the whole, raw toolkit isn’t necessary, but of course as illustrated here, they are available if you wanted to go that route. But, I’m not sure Julia is your best language choice in that case.
  • The complexity of these toolkits, as well as the corresponding complexity of the IDEs (esp. drag and drop interface builders) for working with them isn’t necessary for building UIs for internal SEA tools, and that level of developer investment on the UI isn’t consistent with the workflow and priorities of the users, in my experience. This is why we see the rise of low-code/no-code tools in the business internal tools world (e.g. ReTool, Outsystems…)

So, frameworks and tooling for developers who support this class of users is where I think there is a sweet spot that Julia can fill. The closest existing solutions are, for example, tools integrated with MATLAB for building apps, and similarly for Mathematica. We’re not far off with Makie and Genie, which would need to be part of this solution due to their broad adoption. However, we don’t want to create another 2- (or 3- or 4-) language problem by requiring UI development to involve HTML+CSS+JS. And it all needs to be integrated with tooling that supports the kind of deployment workflow the OP presents.

I’m very interested in this thread or separately in what kinds of UIs are being built for these types of tools.

Finally,

One thing I really appreciate about the Julia community is the help offered in going after these kinds of issues, and often getting workarounds and fixes out. Trust me, having come from a development community the suppresses bad news, this is really refreshing! Looking forward to working further with everyone on this challenge.

4 Likes
37

When preparing an answer to the NLNET AppBundler.jl grant application, I collected multiple impressive examples in a Slack thread on the GUI applications made in Julia. Perhaps this list can answer your question:

5 Likes
38

This is where webassembly (wasm) comes in. People like me want to make native app which they can also compile for web and get more users on unsupported platforms. e.g. egui.rs and Rebuilding Prime Video UI with Rust and WebAssembly.

39

Thanks – great list! I’ve seen a few of these before, but nice to have many more.

I’m also interested in any internal tools anyone has built that may not be shared publicly; screenshots or descriptions of the controls used and functionality, to the extent possible, would be great.

1 Like
41

On a general note - juliac is an experimental development under a beta version of Julia. Windows adds it’s own specific difficulties. Fortunately there are brave people there who are not afraid of all the frustrations to help the community to improve the tools :wink:. However with all the effort I wouldn’t really expect to it to get production-ready in the close future.

Another solution, which may or may not be acceptable for a use case like yours, would be to instruct the customer to perform a standard Julia installation on their computer, and the let your GUI software execute a Julia script to start a server, talk to the server, and shut it down in the end - all completely transparent.

That’s what I have done with my LVServer.jl + LabVIEW0.jl packages ([ANN] LabVIEW0 - Calling Julia from LabVIEW using ZeroMQ). The communication is over ZeroMQ, the data sent over as json (for large data amounts, sending in binary format was also supported). Unfortunately that all happened to become a solution without a problem, at least for me, but it worked nicely

If there exists a working ZMQ implementation on the Lazarus side: The LVServer.jl can probably be used as is, otherwise easily adapted.

There are also some other packages in the JuliaInterop. See also (may or not be relevant):

2 Likes
42

I reported about PackageCompiler.jl This is a production-ready component of Julia and I cannot get it to work under Windows.
But how is that possible? Only because the developers of PackageCompiler don’t user Windows for their projects.

I will open a new discussion thread for this Windows issue.

58

Please consider AppBundler.jl:

Note it bundles into one “installer-file”, it doesn’t precompile, but rather relies on Julia precompiling from the source code you distribute. I haven’t used it but I understand it might be even better on Windows than on Linux I use.

For the GUI you can consider GitHub - Clemapfel/Mousetrap.jl: Finally, a GUI Engine made for Julia though there are also other options.

And FYI:

2 Likes
59

I had a look and its author,@Janis_Erdmanis also posted in this thread. i think the way to go is PackageCompiler → lib, then using lib either in a C++ program + Qt or in a Lazarus program.

Now that I got PackageCompiler to work I will give the latter a try the next days and report back.

(by the way, since PackageCompiler works well with Julia 1.10, I downgraded to Julia 1.10 and noticed that my programs run faster that with 1.11 when executed the first time)

Regarding Mousetrap.jl, this is a really nice UI. The point with UIs is that for our programs we spend about 80% on the UI until all knobs behave as they should, are only active when they should etc. Therefore we need a UI that is driven by either a company or an active community. Mousetrap had its last commit more than a year ago. If we encounter bugs, we would have to fix them on our own but we don’t have the manpower and knowledge to dive into UI code.

Regarding SyslabCC, I had a look, but its webpage and the linked example leads me to a blank website, with only a menu in Chinese.

3 Likes
60

That’s an entirely reasonable requirement, but that’s generally harder to come by in Julia, a language with relatively smaller user and developer communities. Improving base Julia’s capabilities, like trimmed binaries, could potentially make it feasible for more people to apply or integrate Julia into more things, but that’s not a sufficient condition. There’s plenty of other languages that already have those features yet suffer from ecosystem holes.

Julia’s REPL workflow, which is shared by many other languages, works great for many things, and an interactive JIT really helped development and composability of many packages, but that came with a lot of weaknesses that other languages can avoid with different tradeoffs. I think commenters have been comprehensive about what the current ecosystem can do for the stated goal and upfront about the state of the limitations; we are in the same boat after all. To flip the question of Julia’s limitations, what strengths of Julia are you considering for your project? Precompiling a large/untrimmed PackageCompiler library is strong dedication to using Julia when you’re already writing C++, which is at least as performant and more easily so in some ways, on top of smaller binaries and a strong ecosystem.

2 Likes
61

Hi, after reading this whole thread I feel like it might help you that I share my own experience, although I believe we come from a very different starting point.
I started using julia 4 years ago because I believed in the not Matlab, not python, but efficient to code and to run message.

My experience of julia development of standalone GUIs.

To sum it up, I have almost the same problem as you

  • I work on windows
  • I need to be able to share my work with colleagues that are not familiar with julia
  • I need to build GUIs that use julia as a backend

However I guess I come from a purely scientific background with no experience whatsoever in statically compiled languages, just assume I knew matlab only.

At first I figured, well a compiled (event though JIT compiled) should be callable at some point (again no experience in statically compiled languages, what is a pointer again ?) by other programs.

My use case is basically to connect use julia with .NET GUIs. There again I figured somebody would have done the heavy lifting already. But no, it’s open source ecosystem, so you get what people or companies are willing to share, no more, no less. My cry for help (as well as some other people’s) was summarized in the following posts

Long story short, I could not find an “easy” solution to my problem. So then I figured how to handle it by myself as best as possible. My solution was, after several iterations to

All in all, this was not easy. And saying everything is production ready would be a bold statement. But it is not so bad. Everything works as expected, it “just” required much more work reach that than anticipated. The compiled sysimage is still very big compared to the rest, but it is not dramatic either.

So in a sense what you try to do is feasible, I use it regularly and my colleagues as well. Is it completely robust, and easy, or efficient right now, of course not. Will it reach that, I definitely hope so.

My most recent sources of hope where Mousetrap.jl and QML.jl, but there again, that means I have to move from .NET. And since we have several softwares in .NET it is unlikely. And as you pointed out Mousetrap does not feel trustworthy right now given its update history.

So while I hope somebody will try and make .NET / Julia interop work, I am stuck with my solution.

Windows and julia

I fully understand your frustration about Windows vs other OS because I can only work with windows due to some of the proprietary software we use solely working on that platform.

I surely met some obstacles to work with julia on windows, in particular the fact that some REPL modes do not work completely on windows like the shell mode, but far more important the fact that I cannot use juliaup on my professional computer, my company does not allow the microsoft store, it’s as simple as that.

On the other hand, I find it much easier to work with julia on windows compared to Python, just because Pkg feels amazingly easier to use with regards to environments compared to conda or pip.

Other than that the most problematic thing I had about julia’s way of doing things is that it is very github centric, but in the end that is where the community shined. I wanted to setup CI on local machines, on a Gitlab instance, and while julia itself was not making it easy a lot of people helped me to reach a production level CI

This is only my two cents there, I hope you feel somewhat less lonely with your julia/windows/gui issues.
.

13 Likes
62

What about using MSIX App Installer for juliaup? The institution where I worked previously blocked MS Store, too, but then we could use the MSIX installer.

63

Don’t get it. What is the problem with the julia-1.XXX-win64.exe installer?

  • It let us easily select an alternative installation directory. One that is not a hidden directory, like what the default proposes and don’t know if juliaup shows (never used, nor will use, juliaup on Windows)
  • One can easily choose what Julia version to install, instead of automatically install latest and slowest to start/compile.
64

Friendly mod note here — I just detangled the discussion around the PackageCompiler hang as best I could from this more general purpose brainstorming thread around distributing windows UIs built with (or including) Julia.

There’s already been quite a bit of discussion around Windows installer methods in the concurrent About Julia's development policy regarding Windows topic. Let’s try to keep this topic here focused on building and distributing Windows UIs.

2 Likes
65

If your expectation is something like Lazarus or Delphi, with a GUI builder (with company support, or like C#/.NET) then I think you’ll find nothing similar for Julia. FYI this thread (you can use Julia with other languages, e.g. Delphi, though likely not many have done so before you):

You can expect (I’ve seen up to 100x claimed, also elsewhere, vs Delphi, despite it compiled, and not a slow language/compiler) speedup in runtime with Julia (maybe the reason you adopted Julia, why did you? Did you read misleading claims about the ecosystem?), but development time for the GUI is likely worse. I don’t know which GUI toolkit is best for Julia (haven’t used any of them). None of the GUI options, or web based options, have company support with Julia (one did, for web, then Julia support made unofficial again). Mousetrap is based on Gtk, but understand made simpler, why I suggested it over Gtk or Qt. Qt/QML is another option, has company support (when used natively, i.e. with C++), and I believe it has a GUI builder.

https://www.chiefdelphi.com/t/coroutines-are-way-better-than-commands/438376/24?page=2

I am continually impressed at what Julia language (pyjulia) can do with making julia calls from within python.

If you want to make the GUI with Python, then I suggest PythonCall.jl, not older pyjulia.

I think Julia does not like Windows.

I don’t think that’s true (only minor issues, and Windows not neglected, despite Julia developed first on Linux only), if anything Windows or (its) virus checkers do not like Julia… slowing down, but such Windows issues affect mostly any language equally.

2 Likes