Creating a GUI with Rust; Problems to run Tauri (on FreeBSD)

I have avoided the need to create native applications with a GUI so far, but eventually I'd like to create a program that has a graphical user interface but runs on a local machine (opposed to a web application).

I came across this thread:

Unfortunately it has just been closed 11 hours ago, and I have a few questions yet, so I'm going to ask them in this new thread.

I also stumbled upon Tauri. I tried to follow the guide. I don't fully understand if I need "npm" or not. When I try to follow the first step

npm create tauri-app

I get:

    throw loadError;

Error: Cannot find module 'create-tauri-app-freebsd-x64'
Require stack:
- /usr/home/jbe/.npm/_npx/b58944764482de26/node_modules/create-tauri-app/index.js
- /usr/home/jbe/.npm/_npx/b58944764482de26/node_modules/create-tauri-app/create-tauri-app.js
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:933:15)
    at Function.Module._load (node:internal/modules/cjs/loader:778:27)
    at Module.require (node:internal/modules/cjs/loader:1005:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at Object.<anonymous> (/usr/home/jbe/.npm/_npx/b58944764482de26/node_modules/create-tauri-app/index.js:152:25)
    at Module._compile (node:internal/modules/cjs/loader:1105:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1159:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Module.require (node:internal/modules/cjs/loader:1005:19) {
  requireStack: [
npm ERR! code 1
npm ERR! path /usr/home/jbe/rust-experiment/gui
npm ERR! command failed
npm ERR! command sh -c /tmp/

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/jbe/.npm/_logs/2022-08-25T13_53_03_208Z-debug-0.log

Maybe it's because the npm package for FreeBSD is old? When I install a new npm version through the system's npm as user, it will install a new version but still start the old version when I invoke npm.

 % npm --version

When I try

cargo install tauri-cli

I get:

error[E0425]: cannot find function `bundle_update` in this scope
  --> /home/jbe/.cargo/registry/src/
31 |     let bundle_result = bundle_update(settings, bundles)?;
   |                         ^^^^^^^^^^^^^ not found in this scope

For more information about this error, try `rustc --explain E0425`.
error: could not compile `tauri-bundler` due to previous error
warning: build failed, waiting for other jobs to finish...
error: failed to compile `tauri-cli v1.0.5`, intermediate artifacts can be found at `/tmp/cargo-installkhQ4mP`


I don't know if Tauri is meant to run under FreeBSD at all? I would like my app to run under FreeBSD, Linux, Windows, and macOS.

Maybe I should start with wry first? After a quick search, I didn't see support for FreeBSD either. Though many things made for Linux work on FreeBSD as well.

I just tried the Hello World example in wry's README, and it runs without worries. :grin: So perhaps that's what I'll do. But maybe there are other good alternatives?

Happy to hear about experiences with any sort of toolkit, so I can better decide which way to go. Currently, I'd probably try wry first.

Trying to understand wry's documentation on, I don't really see how I have to use it if I want to create a simple GUI application that runs locally on my machine. The Hello World example opens a website through HTTPS, which isn't what I want. I feel a bit lost and don't know where or how to start. :sweat_smile:

The last time I built a GUI was over two decades ago and on Windows, and otherwise I have only create web applications so far, so my knowledge is very limited. Perhaps someone can give me a good starting point.

wry just provides you with a system web view, if you were using it to build a local gui you would just start a web server in your app process and point wry to that instead of an external URL.

My understanding of tauri is that it's basically a web framework that's been designed specifically for making this kind of "in process web server" model simple to write, but there's no reason you couldn't use any other web server framework with wry to build something.

Hmmmm… :thinking:… and which other web server framework to use? (@rjc2013) I don't want to open a TCP port on the local machine. I guess a better way would be to use local sockets (under Linux/BSD). But can you even do that in Windows?

Note that the Tauri docs say here:

  • DON'T ship any kind of localhost server unless the app needs to talk to other devices

Having to write a whole web application seems to be some overhead, both at runtime and for development.

Right, I'm not saying tauri is necessarily literally just creating a localhost HTTP server, I imagine it's more sophisticated than that.

I was just trying to explain the general principle here of how wry can be used to build a GUI, sorry if that was unclear!

No problem, I'm still pretty unsure myself how/what to do. I understand that there is the idea to make everything HTML5, even local applications, but I have no experience with that.

If I decide instead to go a "classic" way, maybe this book on Rust and GTK could help me.

That's not npm lacking BSD support, it's that it can't find a BSD version of the native bits of Tauri (the Tauri package could be a bit clearer and safer here and not try to fetch packages that don't exist and they might not control!)

I think you're just going to find that BSD isn't supported by Tauri, and have to give up on it for now. To be fair, it only went 1.0 months ago, and I imagine it takes considerable work to develop and test for each platform due to it's nature.

Tauri is a bundle of:

  • TAO: a fork of winit, the wrapper for the platform windowing API (including input, etc ...)
  • WRY: a portable API to the platform's webview
  • A whole bunch of additional platform wrapping code, commonly needed by desktop apps, such as for notifications, tray icons, protocol handlers (app links), and so on.
  • Application packaging and installer tooling appropriate for the platform
  • Other libraries and build tooling to glue the above together into a single tool.

So it's pretty much nothing but platform specific code!

Their roadmap has Android and iOS next, so I imagine they might have BSD support at some point, but not for quite a long time unless someone really steps up to add it - at least it wouldn't be too far off the Linux target?

You might have more luck with some of the toolkit wrapper libraries, or the Rust native GUI libraries on, since they require (and thus only provide) specifically GUI.

1 Like

There's a lot of projects listed there. Where do I find the "Rust native GUI libraries" on that page, or what do you mean exactly with those?

So ironic… Platform independent GUI development that is not portable (yet). :wink:

Chapter 5 revealed a lot of friction (in my opinion) between the C world and the Rust world. Maybe it would get better if I was used more to it. I think there has been a lot of work done to get GTK usable in Rust but I still feel pretty much exposed to C. Not that I mind C, but… when I work in Rust, I'd like to use structs, enums, impl, and not glib::value::Values, glib::variant::Variants, or glib::subclass::types::ObjectSubclasses. These and some more things I stumbled upon:

Maybe it isn't all such a big deal for someone who's used to glib and GTK, but… I just want to make a GUI with Rust, and not learn an entirely new inheritance system. :unamused:

relm wraps gtk in a more idiomatic API, but I don't have any experience with it myself.

1 Like

Most of those are bindings, there's only a dozen or so after that (and I would say half of those should be bindings too) They generally say "pure rust" or something similar, and don't mention DOM or a specific os.

What I mean by that are the libraries that take the OS window and input events from something like winit, and a UI description from you, and render their own interactive widgets.

They're all a bit weak right now, with very limited widgets (I haven't seen an easy way to get a password input yet, for example!), but the notable ones I've tried are:

  • egui: probably the most powerful, but layout is clumsy and it's immediate mode, so performance can be hard
  • druid: easy, but a bit limited when I tried it, and extending it is a lot of work, from memory
  • iced: more architecture than library, I'm not a huge fan of the global command pattern, but I didn't really give it a full try.

There's a couple others I haven't tried yet, fui-core looks cool, for example, but the jist is everything's still pretty early.

Reading the book GUI development with Relm4, it looks quite promising. Still many concepts to learn, but relm4 feels much more "rusty" than using the gtk4 and glib crates directly. You'll still work with items from the gtk4 create, but all the "C noise" has been wrapped away nicely, it seems, if you look at the second full example in the book (the gtk4 crate is brought into scope as gtk there).

So thanks for pointing me there. I might have a more closer look soon.

Nice discussion, thanks for sharing

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.