DEV Community: Davide Del Papa

FreePascal/Lazarus and Rust Integration P.II

Davide Del Papa — Thu, 29 Jan 2026 16:25:14 +0000

In this installment we will see how to show something useful that integrates Rust + Lazarus/Free Pascal.

All the code and more can be found in the linked repo.

A simple JSON <> MessagePack converter

The Rust Library

We want to build a Rust library that handles the conversion between JSON and MessagePack (and viceversa). If you are new to MessagePack, think of it as a "compiled" binary JSON, a way to reduce JSON size bot in transmission and at rest. The problem with MessagePack is that, contrary to JSON, it is not human readable. That is where a JSON <> MessagePack converter could find its use case. So, let's build one!

As for the Rust library, let's create a new lib such as:

cargo new jsonmplib --lib

Let's add what we need:

cargo add serde serde_json rmp-serde base64

Let's have a thought on what we need:

A function to convert JSON to MP (MessagePack)
A function to convert MP to JSON
Data structures to pass around between Rust and Pascal

As MessagePack is a binary format, we will represent it with a struct that can hold a pointer to the binary data (bytes = u8) as a C-style vector, and a dimension of the vector itself (least we read data that is not present in the vector).

#[repr(C)]
pub struct MpBuffer {
    pub data: *mut u8,
    pub len: c_int,
}

In this way we represent a nice old C-Style memory buffer.

To free the buffer's memory we need a function that ca be called also over the fence, on Pascal's side:

#[unsafe(no_mangle)]
pub extern "C" fn free_mpbuffer(buf: MpBuffer) {
    if !buf.data.is_null() {
        unsafe {
            drop(Vec::from_raw_parts(
                buf.data,
                buf.len as usize,
                buf.len as usize,
            ));
        }
    }
}

In the above, if the data pointer is not null we build a vector from "raw parts, i.e., pointer, length and capacity, and then drop it (remember it's an unsafe operation.)

Yes capacity can be different from the length as the length is the dimension of the data, capacity is the reserved space fro the buffer, so that the actual dimension can grow up to take the whole vector capacity; for convenience we will set non-growing buffers (i.e., fixed space), so length and capacity are the same.

Now, onto the first function: convert JSON to MessagePack, saving it in the memory buffer.

First we'll create an empty() constructor for our MpBuffer, so that we can create empty buffers to return when there's no JSON and on error:

impl MpBuffer {
    pub fn empty() -> Self {
        MpBuffer {
            data: ptr::null_mut(),
            len: 0,
        }
    }
}

Then, the actual conversion function:

#[unsafe(no_mangle)]
pub extern "C" fn json_to_msgpack(json_ptr: *const c_char) -> MpBuffer {
    if json_ptr.is_null() {
        return MpBuffer::empty();
    }

    unsafe {
        match CStr::from_ptr(json_ptr).to_str() {
            Ok(json_str) => {
                // Parse JSON
                match serde_json::from_str::<Value>(json_str) {
                    Ok(value) => {
                        // Encode to MessagePack
                        match to_vec(&value) {
                            Ok(vec) => {
                                let len = vec.len();
                                let mut vec = vec;
                                let data = vec.as_mut_ptr();

                                // Avoid dropping the Vec
                                std::mem::forget(vec);
                                let c_len = len as c_int;

                                MpBuffer { data, len: c_len }
                            }
                            Err(_) => MpBuffer::empty(),
                        }
                    }
                    Err(_) => MpBuffer::empty(),
                }
            }
            Err(_) => MpBuffer::empty(),
        }
    }
}

The function is easy enough: we accept a C-style string (pointer) with the JSON, and we convert this to MessagePack, saving it in the buffer.

The first thing we do is to return an empty buffer if the string is empty (pointer to null); then we try to construct the C-string form the pointer, matching the result: on error we return an empty MpBuffer throughout the function.

When we have our Cstring as Ok value, we parse it as JSON, and once this is Ok we encode it to a MessagePack Vec and we get a pointer out of it, and its length (converted to c-Syle int, c_int) to wrap it into the MpBuffer. Finally, when we no longer need it, we do not drop the MessagePack Vec; instead, we use std::mem::forget to "deconstruct" it cleanly.

As for the conversion back from MessagePack to JSON, the process is much easier, as we just return a C-style string (a pointer c_char), so we do not need a memory buffer for it:

#[unsafe(no_mangle)]
pub extern "C" fn msgpack_to_json(data: *const u8, len: c_int) -> *mut c_char {
    if data.is_null() || len == 0 {
        return ptr::null_mut();
    }

    unsafe {
        let slice = std::slice::from_raw_parts(data, len as usize);

        match from_slice::<Value>(slice) {
            Ok(value) => match serde_json::to_string_pretty(&value) {
                Ok(json_str) => CString::new(json_str).unwrap().into_raw(),
                Err(_) => ptr::null_mut(),
            },
            Err(_) => ptr::null_mut(),
        }
    }
}

In the above function we get the MessagePack as data and length, unpacking as to say, the MpBuffer struct, so we can call it by literally unpacking the corresponding Pascal's record.

We get a null pointer on an empty (or null) MessagePack, and throughout the function on error.

For the actual conversion we get a slice from the raw parts of data and length of the memory buffer, and we use the from_slice on it, to convert MessagePack to serde_json's Value. If everything is Ok, we prettify it and return it as a C-string, nice and easy.

Once we have done with the basic functions, the final touch is to have a function that we'll call from Pascal in order to free the memory occupied by the c-strings in Rust:

#[unsafe(no_mangle)]
pub extern "C" fn free_cstring(s: *mut c_char) {
    if !s.is_null() {
        unsafe {
            drop(CString::from_raw(s));
        }
    }
}

If you got the foregoing, this is almost trivial: we just wrap a drop() on a Cstring constructed "from raw" pointer to c_char.

With these data structures and function,we have finished on Rust's side.
Now, after building we can copy the resulting library to the usual places (here I'm on Linux, it must be copied to /usr/lib/, on Windows it's sufficient to copy it at the root of the Lazarus project, near the .exe that will be produced):

cargo build --release
sudo cp target/release/libjsonmplib.so /usr/lib/libjsonmplib.so

We can now pass the ball on Pascal's court to see how to handle this new library.

The Pascal's side of things

We will create a simpledemo folder and a new Lazarus project select a New.. Project/Simple Program called jsonmpdemo. As usual, let's create first the .pas unit jsonmplib.pas to interface with the Rust library:

unit jsonmplib;

{$mode ObjFPC}{$H+}

interface

uses
  Classes, SysUtils;

type
  PMpBuffer = ^TMpBuffer;

  TMpBuffer = record
    Data: pbyte;
    len: longint;
  end;

function json_to_msgpack(jsonStr: pchar): TMpBuffer; cdecl; external 'libjsonmplib';

function msgpack_to_json(Data: pbyte; len: longint): pchar; cdecl; external 'libjsonmplib';

procedure free_mpbuffer(buf: TMpBuffer); cdecl; external 'libjsonmplib';

procedure free_cstring(str: pchar); cdecl; external 'libjsonmplib';

implementation

end.

If you have followed the style we use in the first tutorial, this code shouldn't come with lots of surprises, but let's review it briefly:

we create a TMpBuffer record to map our Rust MpBuffer struct, and a pointer for it (PMpBuffer = ^TMpBuffer)
after this, we map all of Rust's extern C functions to Pascal ones with an external 'libjsonmplib' for each. No implementation needed as the Rust library is the implementation.

Now as for some code to use the unit, inside the jsonmpdemo.lpr:

program jsonmpdemo;

{$mode ObjFPC}{$H+}

uses
  jsonmplib, Classes, SysUtils;

var
  buf: TMpBuffer;
  jsonStr: PChar;
  msgpackStream: TMemoryStream;

begin
  // Convert JSON to MessagePack
  buf := json_to_msgpack(PChar('{"x":1,"y":2}'));

  if (buf.data <> nil) and (buf.len > 0) then
  begin
    msgpackStream := TMemoryStream.Create;
    try
      // Write MessagePack bytes to stream/file
      msgpackStream.WriteBuffer(buf.data^, buf.len);
      msgpackStream.SaveToFile('out.msgpack');
    finally
      msgpackStream.Free;
    end;
    free_mpbuffer(buf);   // Rust-allocated memory must be freed
  end
  else
    Writeln('ERROR: json_to_msgpack returned empty buffer.');

  // Now read from file back into a NEW stream
  msgpackStream := TMemoryStream.Create;
  try
    msgpackStream.LoadFromFile('out.msgpack');
    msgpackStream.Position := 0;

    // Convert MessagePack -> JSON
    jsonStr := msgpack_to_json(msgpackStream.Memory, msgpackStream.Size);

    if jsonStr <> nil then
    begin
      Writeln('Decoded JSON: ', jsonStr);
      free_cstring(jsonStr); // Rust-allocated memory must be freed
    end
    else
      Writeln('ERROR: msgpack_to_json returned NULL.');
  finally
    msgpackStream.Free;
  end;
end.

The only "complication" here is that we're handling FPC's memory streams, as we need to handle MessagePack which of course is a binary stream.

In the code above, we first create a TMpBuffer record using the function json_to_msgpack with a JSON object {"x":1,"y":2} then we save the data (binary part) to a file, using a TMemoryStream to handle the binary format, as said. We then free the streaming, so that the data is lost to the program, and so to prove that we can indeed write and read MessagePack to and from a file. For this reason we free also the record (which is kept in the Rust library's memory, so we use one of the function we prepared in Rust: free_mpbuffer).

Reading back the lost data from the saved file is precisely what we do next: we allocate again the TMemoryStream and we load it with bytes taken from the file we saved earlier. Then we use again the library to convert that byte stream into a JSON object with the function msgpack_to_json, and show it to the user. After this we free again all memory, both in Rust and Lazarus.

Once the program is compiled, the output is as expected:

./jsonmpdemo

Decoded JSON: {
  "x": 1,
  "y": 2
}

It is even pretty printed (the original JSON object was not, remember?).

Advanced GUI

Let's see if we can create a more interesting application out of this library. This time we create a New.. Project/Application in Lazarus.

We need to place graphical components on the main form here called Form1. Take a look at this hierarchy:

Form1: TForm1
  Panel1: TPanel (alTop)
    btnConvert: TButton (alLeft)
    btnReverse: TButton (alLeft)
    CheckBase64: TCheckBox (alLeft)
  Panel2: TPanel (alClient)
    Panel3: TPanel (alLeft)
      Label1: TLabel (alTop)
      Memo1: TMemo (alClient)
    Splitter1: TSplitter
    Panel4: TPanel (alClient)
      Label2: TLabel (alTop)
      Memo2: TMemo (alClient)

You need to replicate the parent/children structure with the same component name: component type I used. In parentheses I placed also the Align property to select. Maybe it's a naive way of creating layouts, but in Lazarus we can go far with nesting panels, splitters and the Align property.

We can copy the jsonmplib.pas we created in the simple app to interface with the Rust library, we don't need to reinvent the wheel here. and then connect the dots.

Here's some code to get you going.

unit main;

{$mode objfpc}{$H+}

interface

uses
  Classes, SysUtils, Forms, Controls, Graphics, Dialogs, ExtCtrls, StdCtrls,
  jsonmplib;

type

  TDataFormat = (dfJSON, dfMsgPack);

  { TForm1 }

  TForm1 = class(TForm)
    btnConvert: TButton;
    btnReverse: TButton;
    CheckBase64: TCheckBox;
    Label1: TLabel;
    Label2: TLabel;
    Memo1: TMemo;
    Memo2: TMemo;
    Panel1: TPanel;
    Panel2: TPanel;
    Panel3: TPanel;
    Panel4: TPanel;
    Splitter1: TSplitter;
    procedure btnConvertClick(Sender: TObject);
    procedure btnReverseClick(Sender: TObject);
    procedure FormCreate(Sender: TObject);
  private
    FLeftFormat: TDataFormat;
  public

  end;

var
  Form1: TForm1;

implementation

{$R *.lfm}


{ TForm1 }

procedure TForm1.FormCreate(Sender: TObject);
begin
  FLeftFormat := dfJSON;  // left starts as JSON
  Label1.Caption := 'JSON';
  Label2.Caption := 'MessagePack';
end;

procedure TForm1.btnReverseClick(Sender: TObject);
var
  tmp: string;
begin
  // swap captions
  tmp := Label1.Caption;
  Label1.Caption := Label2.Caption;
  Label2.Caption := tmp;

  // swap memos visually
  tmp := Memo1.Text;
  Memo1.Text := Memo2.Text;
  Memo2.Text := tmp;

  // toggle the state
  if FLeftFormat = dfJSON then
    FLeftFormat := dfMsgPack
  else
    FLeftFormat := dfJSON;
end;

procedure TForm1.btnConvertClick(Sender: TObject);
var
  inp: string;
  outp: PChar;
  buf: TMpBuffer;
  ms: TMemoryStream;
begin
  inp := Memo1.Text;

  if FLeftFormat = dfJSON then
  begin
    // JSON -> MessagePack
    buf := json_to_msgpack(PChar(inp));
    try
      if (buf.Data <> nil) and (buf.len > 0) then
      begin
        ms := TMemoryStream.Create;
        try
          ms.WriteBuffer(buf.Data^, buf.len);
          ms.Position := 0;
          Memo2.Lines.Clear;
          Memo2.Lines.Add('(binary msgpack, ' + IntToStr(buf.len) + ' bytes)');
        finally
          ms.Free;
        end;
      end;
    finally
      free_mpbuffer(buf);
    end;
  end
  else
  begin
    // MessagePack -> JSON
    // Memo1 contains *text* describing MessagePack; in practice, this
    // will be raw binary loaded as hex or pasted, but for now assume raw bytes.
    {
      For now let's assume the user manually loads raw msgpack into Memo1.
      We need to fix this later on.
    }

    // Convert Memo1.Text to a byte buffer
    ms := TMemoryStream.Create;
    try
      ms.Write(PChar(inp)^, Length(inp));   // naive, for now
      outp := msgpack_to_json(ms.Memory, ms.Size);
      try
        if outp <> nil then
          Memo2.Text := outp;
      finally
        free_cstring(outp);
      end;
    finally
      ms.Free;
    end;
  end;
end;


end.

The above code works, but it doesn't show anything on the MessagePack part, as we cannot really dump binary into the text memos as-is, nor can we switch and convert from MessagePack to JSON: the program in this state is not yet functional.

Going the Extra Mile: Handling Base64

In the companion repository (and in the interface we used as layout) you can see an option to handle base64: we do not just signal that we can handle the binary data, we can actually use base64 to show this and even exchange MessagPack data with web APIs (which are incapable of dealing with binary as is, but love the base64 encoding of it).
We added also a hex dump, so there's something to show for all the effort done when we are not using the base64.

Refer to the JSONMPConv/JMPC/ folder in the companion repository.

As usual, I hope this tutorial was useful for you, so if you want, leave a comment below.

FreePascal/Lazarus and Rust Integration

Davide Del Papa — Mon, 05 Jan 2026 13:38:54 +0000

Code available on Github

Going thorugh the TIOBE Index we can find that constantly, in the top 10 of the most popular languages, one find that constantly there are some "old" languages that "refuse to die." Among those we find the Delphi/Object Pascal, at the moment of writing it's on the 9th position, or Visual Basic, at the 7th position. Instead, new languages, like Rust can be found more often than not, below the top 10 (at the moment of writing, Rust is on the 13th position, behind both Perl and Fortran). Be it far from trying to give reaons for the popularity of a language instead of another; may it be the sheer amount of codebases still mantained in those languages, or other reasons, the fact is that those languages are still in use.

Seeing this I got thinking that maybe there is a potential benefit in talking about languages integration. So, why not integrate Rust and Pascal? In my case I'm presenting the Free Pascal dialect, and the Lazarus IDE (because I'm biased over Open Source), but the code can be adapted easily to other Pascal dialects.

This tutorial is split in two: in the first part I will present to you the "theory",a nd we will make up some contieved examples, and, while using Lazarus (which is a RAD IDE), we will concentrate on simple commandline Pascal applications (although in the companion Github repository there is an example of GUI usage). In the second part instead, we will produce a proper GUI application, with some real world usage, so stay tuned!

Hello, World!

Let's start with a sort of "hello world" integration: a simple Rust function that adds two numbers and a Pascal program that calls the function.

Rust Side

On the Rust side, let's create a library to be used by the Pascal code, which we will call rustlaz.

cargo new rustlaz --lib
cd rustlaz && zed .

I write zed ., but you can write hx ., code ., or whichever editor you are using.

In Cargo.toml make sure we compile a library:

[lib]
crate-type = ["cdylib"]

While in src/lib.rs we can create a dummy function:

#[unsafe(no_mangle)]
pub extern "C" fn add_numbers(a: i32, b: i32) -> i32 {
    a + b
}

The #[unsafe(no_mangle)] will make sure that the function is ready to be called by an external language, and of course, the function itself must be pub extern "C" to leverage C-style FFI (Foreign Function Integration).

Now a build will give us a .so, a .dll, or a .dylib, according to our system (Linux, Windows, o Mac).

cargo build --release

We need to copy the compiled library from /target/release/ into the root of the Lazarus project for a Windows system. In Linux instead, we need to copy it where the linker can see it, usually /usr/lib/:

sudo cp target/release/librustlaz.so /usr/lib/librustlaz.so

Lazarus Side

We start the Lazarus IDE and we select a New.. Project/Simple Program. We can save it in the root of our project as LazRust.lpi. In the companio Github repo this folder is called lazrust/.

At this point, before writing our program, we need to create a New unit and save it as RustLib.pas This unit will take care of integrating a C-style library interface, mapping it to Pascal functions.

This is the actual content of the unit:

unit RustLib;

{$mode ObjFPC}{$H+}

interface

uses
  Classes, SysUtils;

function add_numbers(a: LongInt; b: LongInt): LongInt; cdecl; external 'librustlaz';

implementation

end.

With this we declare the interface of the function add_numbers of our external libray, so that we can use it in Lazarus freely. Seing how easy it is to call into freing functions in Pascal, no wonder it's a widespread and loved language.

Now we can go back to our main program and use the function:

program LazRust;

uses RustLib;

begin
  Writeln('Rust says 2 + 3 = ', add_numbers(2, 3));
end.

Once compiled (SHIFT+F9), we can launch the program on the command line and see the result:

./lazrust

Rust says 2 + 3 = 5

We can even make a standard GUI program that uses the library and in the folder LazRust2/ you will find an example that leverages the events onEditingDone of two edits to update a label. Feel free to take a look at the code.

A Slightly More Complex Example

We can complicatre a little the interface if we create a Point struct and we pass it around between Rust and Free Pascal.

In Rust, rustlaz/src/lib.rs:

use std::os::raw::c_int;

#[repr(C)]
pub struct Point {
    pub x: c_int,
    pub y: c_int,
}

#[unsafe(no_mangle)]
pub extern "C" fn move_point(p: Point, dx: c_int, dy: c_int) -> Point {
    Point {
        x: p.x + dx,
        y: p.y + dy,
    }
}

Now we have a struct and a function to handle that struct.
We can compile it (release mode) and copy again the library wherever visible by Lazarus (see notes above).

Now in lazarus again, we create a New.. Project/Simple Program.

The RustLib unit must look like the following:

unit RustLib;

{$mode ObjFPC}{$H+}

interface

uses
  Classes, SysUtils;

type
  TPoint = record
    x: LongInt;
    y: LongInt;
  end;

function move_point(p: TPoint; dx: LongInt; dy: LongInt): TPoint; cdecl; external 'librustlaz';

implementation

end.

In this way we "reconstruct" the Rust struct interface mapping it to a Pascal record called TPoint, and we link the FFI function to iterface with the TPoint as it were a Rust struct.
In this way, mapping one to one data structures and functions, we achieve 100% compatibility between the two languages.

Now onto our lazrust.lpr:

program lazrust;

uses RustLib;

var
  P: TPoint;
  P2: TPoint;

begin
  P.x := 10;
  P.y := 20;

  P2 := move_point(P, 3, -2);

  Writeln('Original: (', P.x, ', ', P.y, ')');
  Writeln('Moved:    (', P2.x, ', ', P2.y, ')');
end.

The above code is easy enough; the usage in fact gets quite natural in Pascal.

Once compiled (SHIFT+F9), we can launch the program on the command line and see that indeed we are able to pass a Pascal record as a struct to Rust, and get the Rust struct back, mapped onto a record.

./lazrust

Original: (10, 20)
Moved:    (13, 18)

You can check the code in lazrust3/

Handling Strings and Memory

Our third example is more complex still, as it involves managing strings and memory from both Rust and Pascal sides, to avoid memory leaks and unsafe behavior.

We start from Rust were we create a struct and a function that manipulates it (accepting that struct as a parameter, and returning a changed struct):

use std::ffi::{CStr, CString};
use std::os::raw::{c_char, c_int};

#[repr(C)]
pub struct Person {
    name: *mut c_char,
    office: *mut c_char,
    phone: *mut c_char,
    age: c_int,
}

/// Utility to convert &str to *mut c_char.
fn make_cstring(s: &str) -> *mut c_char {
    CString::new(s).unwrap().into_raw()
}

/// Utility to convert *mut c_char to Rust String.
unsafe fn to_rust_string(ptr: *mut c_char) -> String {
    if ptr.is_null() {
        String::new()
    } else {
        unsafe { CStr::from_ptr(ptr).to_string_lossy().to_string() }
    }
}

/// Free CStrings.
#[unsafe(no_mangle)]
pub extern "C" fn free_cstring(s: *mut c_char) {
    if s.is_null() {
        return;
    }
    unsafe {
        drop(CString::from_raw(s));
    }
}


#[unsafe(no_mangle)]
pub extern "C" fn verify_person(p: Person) -> Person {
    unsafe {
        let name = to_rust_string(p.name);
        let office = to_rust_string(p.office);
        let phone = to_rust_string(p.phone);

        // Add "(verified)" to the name
        let new_name = format!("{} {}", name, "(verified)");

        Person {
            name: make_cstring(&new_name),
            office: make_cstring(&office),
            phone: make_cstring(&phone),
            age: p.age,
        }
    }
}

Besides the Person struct and the verify_person() function, in the above code we see two utilities (one to convert CStrings, i.e. *mut c_char, to Rust Strings, and one to create CStrings starting from &str).
We can see also a function to free a CString: we will call it from the Pascal side, so that Rust will properly free the allocated CStrings, and those memory spaces will not leak.

Having seen the Rust side of things, let's go over the Pascal side. We create a projectt as usual, and we map the Rust library with the usual Pascal unit, but this time with a twist:

unit rustlib;

{$mode ObjFPC}{$H+}

interface

uses
  Classes, SysUtils;

type
  PPerson = ^TPerson;

  TPerson = record
    Name: pchar;
    office: pchar;
    phone: pchar;
    age: longint;
  end;

function verify_person(p: TPerson): TPerson; cdecl; external 'librustlaz';
function free_cstring(s: pchar): longint; cdecl; external 'librustlaz';

function NewCString(const S: string): pchar;

implementation

function NewCString(const S: string): pchar;
var
  Len: SizeInt;
begin
  Len := Length(S) + 1; // include null terminator
  Result := StrAlloc(Len);
  StrPLCopy(Result, S, Len);
end;

end.

As you can see, besides mapping the Person struct with a TPerson record, and besides exposing both the verify_person() and the free_cstring() functions, we have an utility in this unit as well: the function NewCString().
This utility will allocate the memory needed for a string and copy it over to the caler: we will use it to initialized the CStrings inside the struct to pass over to Rust.

Let's have a look at the actual program's code:

program lazrust;

uses rustlib, SysUtils;

var
  P, P2: TPerson;

begin

  P.name := NewCString('John Doe');
  P.office := NewCString('IT');
  P.phone := NewCString('555-0101');
  P.age := 28;

  P2 := verify_person(P);

  Writeln('Rust returned:');
  Writeln('  name:   ', P2.name);
  Writeln('  office: ', P2.office);
  Writeln('  phone:  ', P2.phone);
  Writeln('  age:    ', P2.age);

  // Free Rust-allocated strings
  free_cstring(P2.name);
  free_cstring(P2.office);
  free_cstring(P2.phone);

  // Free Pascal-allocated strings
  StrDispose(P.name);
  StrDispose(P.office);
  StrDispose(P.phone);

end.

A you can see, we allocate the strings in the Pascal record to pass over to Rust (we do so with the utility we created above). After we finish, we use the expose Rust function free_cstring() to dispose of the allocated memory on the Rust side; however, we need to de-allocate the memory also on the Pascal's side: that can leak too.

Admittedly, we have a lot of clean up to do, but it is so, because we cannot use strings managed entirely by Rust, nor can we use the corresponding strings managed entirely by Pascal. Since we are working on the interoperability of these two language, we have to clean up the used resources by ourselves, intead of relying on managed types.

Other than the hygene nuissaces, that makes the code a tad more verbose, the interoperativity between the two languages seems really good.

The above code can be found in the lazrust4/ folder.

Conclusion

All in all the interfacing between Rust and Free Pascal goes really smooth. When facing the problem of renovating a whole legacy codebase, it is comforting to know that so much could be done by just re-writing and extending some key libraries with modern and secure Rust code. The possibilities are endless here. Not the least of them all is the fact that Lazarus can provide a way to create GUIs in an easy and time tested way: instead of chasing the chimera of a Rust only codebase, delegating some key features to other languages, sometimes is the smartest move available.

Stay tuned for Part II of this mini series.

Leptos + Tauri Tutorial

Davide Del Papa — Sun, 01 Sep 2024 17:27:45 +0000

Photo by Toa Heftiba on Unsplash, cropped

Summer for me is over, and I realized it has been a long time since I posted my last blog. Lately, I've accepted a job which involves the programming on a very specific, proprietary and rather backward piece of software (innuendo intended), it's also a long time I have no fun programming.

Bad, very bad: one should never forget that coding is fun. Let's remedy that.

This is the repo connected to the post.

Isometric Rust for Your Stack

Definitely skip this rant, and start reading from next section: Setup a basic Envronment. I mean it: it's useless stuff for the sake of the tutorial. It's just me doing me stuff.

I'm not here to present Leptos or Tauri, for that, just clik the links, ask Goole, or ClaudePilotGPTWhateverLLama... I'm not even here to make just a tutorial on how to get the two working -- if you see Tauri documentation on it is quite "terse," but still enough.

What I want to do here is to give you a walkthough, a repo you can copy from, and also sprinkle it all with some considerations of my own.

I did say to skip this stuff, now it's the moment.

First consideration: forget about isometric Rust. It's true, with Leptos + Tauri you can achieve the goal of programming in Rust full-stack. that is, if you want to do just a Hello World program, you can do it entirely in Rust; but, let's face the truth: we cannot truly escape from JavaScript. JS is everywhere in the background, JS is present as glue to various moving parts of the stack. At the actual state of things, it's impossible to create some WASM functions and not have at least some JS snippets that call said WASM functions.

Anyway, why would you want to avoid JS? It's full of little, well-written JS libraries out there, ready to be integrated into our stack, so why not take advantage of this ecosystem, instead of re-inventing the wheel over and over again?

Besides JavaScript there's HTML and CSS, let's not forget it. Leptos own view! macro syntax mimicks HTML!

That said, in this tutorial we will not pretend we live on a Rust moon and try to achieve isometric Rust; instead, we will get down to earth and do things proper.

Enugh ranting, let's begin!

Setup a Basic Environment

To follow this part of the tutorial you can git pull https://github.com/davidedelpapa/leptos-tauri.git and checkout this tag: git checkout v1.1

First the tools we will need:

cargo install trunk
cargo install leptosfmt # optional, but useful
cargo install create-tauri-app
cargo install tauri-cli --version '^2.0.0-rc'

Note that for Tauri there are some dependencies to set, so follow this guide

Now, let's add the target wasm32 with rustup, if not already done:

rustup target add wasm32-unknown-unknown

Now let's create the Tauri app:

cargo create-tauri-app --rc -m cargo -t leptos -y leptos-tauri && cd leptos-tauri

We will use Rust nightly, at least for this project:

rustup toolchain install nightly
rustup override set nightly

The last command must be done inside the project root to set it project wide, and leave stable Rust for all your other projects (to set it system-wide: rustup default nightly, but I wouldn't recommend doing that).

Now we can add our Leptos dependencies:

cargo add leptos --features=csr,nightly
cargo add console_error_panic_hook
cargo add console_log
cargo add log

The first adds leptos with csr and nighlty features, the second adds console_error_panic_hook which is useful in order to use the browser inspector and get some sensible Rust-like error messages (at least the lines that caused the error), instead of the default link to the wasm bundle and unhelpful messages.

console_log is needed in order to log to the browser console.

Now let's create all the additional files we need to make this work.

The following is for the formatters. Inside the project root, let's add a rustfmt.toml file, to set the correct edition:

# rustfmt.toml
edition = "2021"

Let's add also a rust-analyzer.toml that will help us to override the default rustfmt and use leptosfmt instead:

# rust-analyzer.toml
[rustfmt] 
overrideCommand = ["leptosfmt", "--stdin", "--rustfmt"]

FInally, let's configure leptosfmt with the leptosfmt.toml file:

# leptosfmt.toml
max_width = 120 # Maximum line width
tab_spaces = 4 # Number of spaces per tab
indentation_style = "Auto" # "Tabs", "Spaces" or "Auto"
newline_style = "Auto" # "Unix", "Windows" or "Auto"
attr_value_brace_style = "WhenRequired" # "Always", "AlwaysUnlessLit", "WhenRequired" or "Preserve"
macro_names = [ "leptos::view", "view" ] # Macro to be formatted by leptosfmt
closing_tag_style = "Preserve" # "Preserve", "SelfClosing" or "NonSelfClosing"

# Attribute values with custom formatters
[attr_values]
class = "Tailwind" # "Tailwind" is the only available formatter for now

Noise. Enough with configuration files, let's do something in src/main.rs. Tauri already created main.rs and app.rs for us, so we need to add few lines to src/main.rs:

// src/min.rs
mod app;

use app::*;
use leptos::*;

fn main() {
    console_error_panic_hook::set_once();
    _ = console_log::init_with_level(log::Level::Debug);
    mount_to_body(|| {
        view! {
            <App/>
        }
    })
}

Let's explain the code a little bit, for those who are new with Leptos:

We initialize console_error_panic_hook with the set_once() function.
We also use console_log::init_with_level() to correctly init the logging on the web browser console of any error
mount_to_body is a leptos function to mount a IntoView type to the body of the page. In this case we pass it a function that returns a IntoView type through the view! macro. This macro accepts HTML-like syntax, and in this case we pass to it a custom component that we need to create in the module mod app.

Now we need to take care of said App component inside src/app.rs (already created by Tauri's template for us); replace all the content of the file with the following:

// src/app.rs
use leptos::*;

#[component]
pub fn App() -> impl IntoView {
    let (count, set_count) = create_signal(0);

    view! {
        <div>
            <button on:click=move |_| {
                set_count.update(|n| *n += 1);
            }>"+1"</button>
            <button on:click=move |_| {
                set_count.update(|n| *n -= 1);
            }>"-1"</button>
            <p class:red=move || count() < 0>"Counter: "{count}</p>
        </div>
    }
}

At the heart, a component can be just a function that returns an IntoView type, marked by #[component]. The name of the function will be the name of the component, that is why we wrote it with a capitalized first letter (yes, it's a React-like style).
At the beginning of our function, we set a signal, which is a reactive type, meaning that it can change during the WASM app lifecycle, and in turn make the component change because of it. We use create_signal() which initializes a type given to it as parameter, and returns a getter and a setter for the reactive type thus created, in this case count and set_count respectively.
We then use the view! macro which returns an IntoView, and accets a HTML-like syntax mixed with Rust. We create a <div> containing two <button> and a <p>. We can pass a move closure to the on:click parameter of the button component, where we update the value in the signal we created earlier. We update the signal's value using the update() function on the signal's setter. The update() function accepts a closure where the parameter is the current value of the signal. With this method we creatd a button that increases the counter and a button to decrease it
Inside the view! macro we also use the signal getter (simply {count} for the rendering in view!, but count() if needed inside a closure). The getter will visualize the current value of the signal. Notice also that we conditionally assign a class to the <p> only if the value of the signal is less than 0, with the syntax class:<value>=<move closure>

To render the view! inside the fn main() we decared that it will be mounted to the <body> of the page, but which page? Tauri already created for us a index.html file for it, so we dont need to worry; moreoer the template created also a styles.css imported in the index. In this way, we just need to add the following style to the already created styles.css:

/* Append this at the end of styles.css */
.red {
    color: red;
}

This .red CSS class will be condiionally assigned to the <p> inside our <App> component as we saw earlier.

Now if all went well, running trunk should show our Leptos app inside our favorite browser:

trunk serve --open

Notice that if the --open flag does not work, it is sufficient to point the browser to localhost:1420

Adding Back Tauri Integration

We deleted everything in src/app.rs, but in those lines there was also an example of Tauri integration. Now we can bring back our own integration code and understand things a little better, step by step.

Presently the first thing we will do is to launch the tauri app proper with:

cargo tauri dev

With this we launched th app inside a desktop Tauri app, instead of the browser. Notice that with <ctrl>+<shift>+i we have an inspector even in the tauri window... sweet!

Now, let's take care of creating some Tauri integration, as said.

To follow this part of the tutorial you can checkout this tag: git checkout v1.2

When we used cargo create-tauri-app the leptos template we used added a src-tauri/ folder we ignored so far. Inside this foder, we have a src-tauri/main.rs and a src-tauri/lib.rs.

The main.rs is minimal and it is used to basically call the leptos_tauri_lib::run().

The src-tauri/lib.rs instead is where we can put some functions to be called by the leptos front-end.

What we have already is the following:

// src-tauri/lib.rs
#[tauri::command]
fn greet(name: &str) -> String {
    format!("Hello, {}! You've been greeted from Rust!", name)
}

#[cfg_attr(mobile, tauri::mobile_entry_point)]
pub fn run() {
    tauri::Builder::default()
        .plugin(tauri_plugin_shell::init())
        .invoke_handler(tauri::generate_handler![greet])
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

We have a custom fn greet() that is a function annotated as a #[tauri:command]. This function is passed to the tauri::Builder in fn run() by generating a invoke_handler. Let's change this file to have an increase and decrease command to use for the counter.

This is the new src-tauri/lib.rs:

// src-tauri/lib.rs
#[tauri::command]
fn increase(count: i32) -> i32 {
    count + 1
}

#[tauri::command]
fn decrease(count: i32) -> i32 {
    count - 1
}

#[cfg_attr(mobile, tauri::mobile_entry_point)]
pub fn run() {
    tauri::Builder::default()
        .plugin(tauri_plugin_shell::init())
        .invoke_handler(tauri::generate_handler![increase, decrease])
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

As you can see, we created two tauri::command increase and decrease. Then, in the tauri:Builder inside the run() function (which is the main entry-point for the tauri app), we pass them to the invoke_handler(); the rest is all boiler-plate.

Back to our src/app.rs, we need to let our App component use these two functions (tauri commands).

The first thing we need is to add the needed use statements:

// src/app.rs
use leptos::*;
use leptos::leptos_dom::ev::MouseEvent;
use serde::{Deserialize, Serialize};
use serde_wasm_bindgen::to_value;
use wasm_bindgen::prelude::*;

We added the MouseEvent from leptos::leptos_dom::ev::MouseEvent, which will let us handle the creation of a custom closure for the on:click in our buttons.

We imported Deserialize and Serialize from serde, and to_value from the serde_wasm_bindgen, and of course the wasm_bindgen itself, because we need to pass arguments from the Rust frontend to the Tauri backend, passing through JavaScript (Remeber the rant I told you to skip? Just forget it already).

Now, with an external call to the wasm_bindgen we bind to a generic JavaScript function invoke that is meant to call the Tauri commands:

#[wasm_bindgen]
extern "C" {
    #[wasm_bindgen(js_namespace = ["window", "__TAURI__", "core"])]
    async fn invoke(cmd: &str, args: JsValue) -> JsValue;
}

At the end of the day, it's just boiler-plate to setup at the beginning of our components; then we can use this to bridge from the front-end to the back-end.

Next, we create a struct to pass arguments to our Tauri commands:

#[derive(Serialize, Deserialize)]
struct CounterArgs {
    count: i32,
}

The struct will be converted to a JsValue by serde and it's ready to be passed to the invoke function as argument.

Finall there's our component. After the signal we need to create two closures to communicate with the Tauri commands. We will discuss just the increase_me, but the considerations are valid for both closures:

let increase_me = move |ev: MouseEvent| {
    ev.prevent_default();
    spawn_local(async move {
        let count = count.get_untracked();
        let args = to_value(&CounterArgs { count }).unwrap();
        let new_value = invoke("increase", args).await.as_f64().unwrap();
        set_count.set(new_value as i32);
    });
};

In the closure we need to specify that the parameter ev is a MouseEvent type, so we can bind the closure to the on:cick of our button.

With ev.prevent_default(); we prevent the usual event behaviour, since we will provide our own behaviour. This is the same as the Event: preventDefault() method - Web APIs | MDN in the Web API. It is particularly useful for closures that have to handle <input> fields.

We then spawn a thread-local Future with Leptos' spawn_local(), providing an async move closure. This is needed because when we use the invoke bridge, it will return a Future, that is a promise in JavaScript and async in Rust. This is because the Tauri commands are syncronous.

Inside the closure we get the count signal's value with count.get_untracked(). We need the get_untracked() because in this way we prevent the reactive binding that usually is produced with Leptos signals, so that even if the value in the count changes, Leptos will not try to update the closure.

We then create the argument to be passed to the invoke. We use the CounterArgs structure.

We finally invoke the increase command, and retrieve the new value for the counter, which we use to set the signal with its set() provided method. Since the wasm_bindgen::JsValue that gets returned by the invoke bridge does not convert to integers, we need to convert it to f64 first, and then coherce it to a i32 value.

FYI these are the conversions available for a wasm_bindgen::JsValue:

as_bool which returns an Option<bool>

as_f64 which returns an Option<f64>

as_string which returns an Option<String>

Here is the whole src/app.rs code:

// src/app.rs
use leptos::leptos_dom::ev::MouseEvent;
use leptos::*;
use serde::{Deserialize, Serialize};
use serde_wasm_bindgen::to_value;
use wasm_bindgen::prelude::*;

#[wasm_bindgen]
extern "C" {
    #[wasm_bindgen(js_namespace = ["window", "__TAURI__", "core"])]
    async fn invoke(cmd: &str, args: JsValue) -> JsValue;
}

#[derive(Serialize, Deserialize)]
struct CounterArgs {
    count: i32,
}

#[component]
pub fn App() -> impl IntoView {
    let (count, set_count) = create_signal(0);
    let increase_me = move |ev: MouseEvent| {
        ev.prevent_default();
        spawn_local(async move {
            let count = count.get_untracked();
            let args = to_value(&CounterArgs { count }).unwrap();
            let new_value = invoke("increase", args).await.as_f64().unwrap();
            set_count.set(new_value as i32);
        });
    };
    let decrease_me = move |ev: MouseEvent| {
        ev.prevent_default();
        spawn_local(async move {
            let count = count.get_untracked();
            let args = to_value(&CounterArgs { count }).unwrap();
            let new_value = invoke("decrease", args).await.as_f64().unwrap();
            set_count.set(new_value as i32);
        });
    };
    view! {
        <div>
            <button on:click=increase_me>"+1"</button>
            <button on:click=decrease_me>"-1"</button>
            <p class:red=move || count() < 0>"Counter: "{count}</p>
        </div>
    }
}

Conclusion

Now with a

cargo tauri dev

We can appreciate our counter being increased or decrased as it was before, but using code from the back-end.

Granted, it feels the same (there should not even be any appreciable decrease in speed), however this example can be adapted to do a whole deal more useful stuff in the back-end and present it on the front-end as needed.

If you are still here, that means you have successfully glossed over all my rants and (maybe) finished the tutorial. Hope this has been instructive, feel free to comment below.

Redis Hackathon Submission for Whatstore App

Davide Del Papa — Sun, 28 Aug 2022 23:12:33 +0000

Overview of My Submission

Link to the Repo

Whatstore is an ecommerce store. However, this is no ordinary web-based store, Whatstore is a chatbot based on Meta Whatsapp Business platform.

This has been chosen because many people do not have (easy) access to a computer, or the possibility (and willingness) to browse for an e-commerce, even on mobile. Think for example at the elderly. Instead, many people know and use IM apps, such as Whatsapp, to communicate with friends and family. Many still save their local groceries, pharmacy, or pizza store phone numbers, and text them often to order their groceries. During the Covid 19 pandemic, this has been for many the best option to deal with the rules and needs of social distancing.

However, many times the little stores are not able to attend all the customers by phone. This actually happened to me one evening, when I phoned four different pizza stores to try to get an order, and had to phone each repeatedly, until at last one of them attended me. This brought me to think that orders could be more efficient if we could just use a chatbot. But, where I am located not every grocery is even on socials, let alone have the funds or time necessary to set up such an interface. It came to my mind that everybody here around passes a lot of time answering to texts (and here around Whatsapp is the most used platform), so why not to take advantage of this?

This is the spark that brought me to implement this project.
For the project I actually created data for a fake pizza store, set in a touristic location nearby (where I actually am sure there are no pizza stores, just not to incur in some copyright violations). So when you install this app, you can actually start to order my favorite pizzas!

Submission Category:

Microservice Mavens

Language Used

Node.js

Link to Code

davidedelpapa / whatstore

Whatsapp Business Chat Store

Whatstore

Whatsapp Business app to implement a chat-based e-commerce store

How it works

How the data is stored:

Data is stored as JSON objects with the RedisJSON module.

The e-commerce data is stored in various keys
- A store:info key holds all the info related to the store
- product:* keys hold data for the products
- category:* keys hold data for the products' categories
- user:* keys hold information about the user-sessions, like the cart
- purchase:* keys hold information about completed purchases

How the data is accessed:

Store info
- Get store info: JSON.GET store:info $
- Set store info: JSON.SET store:info $ {store-info-objec}
Product info
- Get product info: JSON.GET product:{product-id} $
- Set product info: JSON.SET product:{product-id} $ {product-info-objec}
Product category info
- Get category info: JSON.GET category:{category-id} $
- Set category info: JSON.SET category:{category-id} $ {category-info-objec}
- Get all categories: KEYS category:*
User information
- Get user info: JSON.GET user:{user-phone-number} $
- Set user info: JSON.SET user:{user-phone-number} $ {user-info-objec}
- …

View on GitHub

Additional Resources / Info

I'm using Node.js, NPM, ngrok, express and whatsappcloudapi_wrapper, as well as pdfkit, uuid, node-fetch v.2, loglevel.

And of course, Redis and RedisJSON

This is the actual workflow of the app:

First you need to ping the business number from you number, it does not matter what you write. It will answer with a choice to either view the products or to speak to a human.

If you choose "Speak to a human" it sends a vCard for the customer care contact; otherwise the app will present to you the product categories choice.

Now you can choose a category and then be presented with a choice of products in that category.

Here we selected the classic pizzas, and now we are going to select a "Salame(Pepperoni)"
We are presented with the details of our selection, and we can now choose to add the product to the cart or browse for some more products. Let's add it to the cart.

We can now review the cart, before checking out, or browse some more products to add. Let's review and checkout!

We can also modify the cart before checkout

After checking out, the app notifies the seller of a new incoming order, and presents to the buyer some options to either again talk to a human or browse more products to shop.

We have accomplished our purchase!

On the seller side, the seller number gets notified of the incoming order, together with all the info needed to prepare the order. The seller has the possibility to send the buyer a notification of when the order will be ready, or fulfill the order right away. Finally the seller can review all pending orders.

At any time the seller can ping their app to check how many pending order are present and view each of them.
Finally, when the order is fulfilled (ideally when the buyer comes to pick up the orders), the app saves the purchased order to the database as a purchase order. This could be used for statistics.

Collaborators

Just me, davidedelpapa - Davide Del Papa.

Rust for Data Science: Tutorial 1

Davide Del Papa — Tue, 24 Aug 2021 15:14:37 +0000

[Photo by jim gade on Unsplash,
modified]
Data Science: a branch of computer science that studies how to use, store, and analyze data in order to derive information from it.

With this mini-series we are going to explore how to use some Rusty tools to accomplish the tasks that are the bread and butter of any Data Scientist.

The final goal is to show that Rust can be employed in this field, and how so. Ultimately our goal is also to sparkle interest in this field of application: the author is persuaded that Rust should prove very useful in the field of Data Science (as well as Machine Learning and ultimately AI).

You can find this article's code in the repo: github.com/davidedelpapa/rdatascience-tut1

Setting the stage for this tutorial

There are few crates we are going to cover in this tutorial. However, we are going to introduce them as we go.

Let's start our project the standard rusty way.

cargo new rdatascience-tut1 && cd rdatascience-tut1
cargo add ndarray ndarray-rand ndarray-stats noisy_float poloto
code .

I am using currently cargo add from the good cargo-edit (quick inst: cargo install cargo-edit) to handle dependencies, and VisualStudio Code as dev IDE.

Feel free to handle Cargo.toml dependencies by hand, or use a different IDE.

ndarray: what is it, and why to use it?

ndarray is a Rust crate used to work with arrays.

It covers all the classic uses of an array handling framework (such as numpy for Python). Some use cases which are not covered by the main crate, are covered through some corollary crates, such as ndarray-linalg for linear algebra, ndarray-rand to generate randomness, and ndarray-stats for statistics.

Additionally, ndarray has got also some nice extra, such as support for rayon for parallelization, or the popular BLAS low-level specs, through one of the working back-ends (using blas-src ).

Why to use ndarray?

In Rust there are already arrays (or lists), and also vectors, and the language itself allows for many different types of manipulation through powerful iterators.

What is more, what is offered by the bare Rust language (enhanced by the std) is many times even faster than other more popular languages; still, ndarray is specialized to handle n-dimensional arrays with a mathematical end in view.

Thus ndarray builds over the power already provided by the language; Rust power is one of the reasons why the author is persuaded that Rust will be the language of Data Science in the next few years.

ndarray Quick-Start

At the top of our src/main.rs we are going to import as usual:

use ndarray::prelude::*;

We have almost everything we need in the prelude.

We can start to put stuff inside the fn main()

Array creation

Let's start to see how we can create arrays:

let arr1 = array![1., 2., 3., 4., 5., 6.];
println!("1D array: {}", arr1);

ndarray provides the array! macro that detects which type of ArrayBase is needed. In this case this is a 1-D, that is, a one dimensional array. Notice that the underlying ArrayBase already implements a std::fmt::Display function.

Compare it to the standard Rust array (let's call them lists in order not to confuse them with ndarray's arrays) and Vec:

// 1D array VS 1D array VS 1D Vec
let arr1 = array![1., 2., 3., 4., 5., 6.];
println!("1D array: \t{}", arr1);

let ls1 = [1., 2., 3., 4., 5., 6.];
println!("1D list: \t{:?}", ls1);

let vec1 = vec![1., 2., 3., 4., 5., 6.];
println!("1D vector: \t{:?}", vec1);

And the result:

1D array:       [1, 2, 3, 4, 5, 6]
1D list:        [1.0, 2.0, 3.0, 4.0, 5.0, 6.0]
1D vector:      [1.0, 2.0, 3.0, 4.0, 5.0, 6.0]

Notice too that array! has written the floats as integers, since they are all .0.

Array Sum

Let's try to sum 2 arrays element by element:

let arr2 = array![1., 2.2, 3.3, 4., 5., 6.];
let arr3 = arr1 + arr2;
println!("1D array: \t{}", arr3);

Let see how it compares with standard arrays(lists) and vectors:

let arr2 = array![1., 2.2, 3.3, 4., 5., 6.];
let arr3 = arr1 + arr2;
println!("1D array: \t{}", arr3);

let ls2 = [1., 2.2, 3.3, 4., 5., 6.];
let mut ls3 = ls1.clone();
for i in 1..ls2.len(){
    ls3[i] = ls1[i] + ls2[i];
}
println!("1D list: \t{:?}", ls3);

let vec2 = vec![1., 2.2, 3.3, 4., 5., 6.];
let vec3: Vec<f64> = vec1.iter().zip(vec2.iter()).map(|(&e1, &e2)| e1 + e2).collect();
println!("1D vec: \t{:?}", vec3);

The result is:

1D array:       [2, 4.2, 6.3, 8, 10, 12]
1D list:        [1.0, 4.2, 6.3, 8.0, 10.0, 12.0]
1D vec:         [2.0, 4.2, 6.3, 8.0, 10.0, 12.0]

As you can see, with Rust standard tools it became more complicated very soon. To perform an element by element sum we need a for or (only for Vec) we need to use iterators, which are powerful, but very complicated to use in such a day-to-day Data Science scenario.

2D arrays & more

let's just abandon quickly the examples using Rust's standard constructs, since as we have shown, they are more complex, and let us focus on ndarray.

ndarray offers various methods to create and instantiate (and use) 2D arrays.

Just look at this example:

let arr4 = array![[1., 2., 3.], [ 4., 5., 6.]];
let arr5 = Array::from_elem((2, 1), 1.);
let arr6 = arr4 + arr5;
println!("2D array:\n{}", arr6);

with its output:

2D array:
[[2, 3, 4],
 [5, 6, 7]]

With the macro array! we need to specify all elements, while with Array::from_elem we need to offer a Shape, in this case (2,1) and an element to fill the array, in this case 1.0: it will fill for us the whole shape with the selected element.

let arr7 =  Array::<f64, _>::zeros(arr6.raw_dim());
let arr8 = arr6 * arr7;
println!("\n{}", arr8);

Which outputs:

[[0, 0, 0],
 [0, 0, 0]]

Array::zeros(Shape) creates an array of Shape filled with zero's.

Notice that sometimes the compiler cannot infer the type of zero to feed in (you almost forgot Rust has got a nice type system, didn't you?), so we help it with the annotation Array::<f64, _>, which gives the type, letting the compiler infer the shape (_).

The function .raw_dim(), as you can imagine, gives the shape of the matrix.

Let's create an identity matrix now (a 2 dimensional array with all 0 but the diagonal)

let identity: &Array2<f64> = &Array::eye(3);
println!("\n{}", identity);

Which outputs:

[[1, 0, 0],
 [0, 1, 0],
 [0, 0, 1]]

We helped the compiler providing the shape and type, but this time using a specialized form of ArrayBase, that is, Array2 that represents 2-dimensional arrays. Notice that we created a reference so that we can re-use the variable without incurring in the ire of the borrow checker (yes, always working, did you forget that as well?)

Let's explore now the use of an identity matrix:

let arr9 = array![[1., 2., 3.], [ 4., 5., 6.], [7., 8., 9.]];
let arr10 = &arr9 * identity;
println!("\n{}", arr10);

Outputs:

[[1, 0, 0],
 [0, 5, 0],
 [0, 0, 9]]

From my math classes I remember something like that the identity matrix should give back the same matrix when multiplied...

Yes, of course, we are not doing dot multiplications! With normal multiplication it does not work.

In fact, when using matrices there is a element-wise multiplication, which is done by arr9 * identity, but there's too a matrix multiplication, which is done by

let arr11 = arr9.dot(identity);
println!("\n{}", arr11);

which finally outputs:

[[1, 2, 3],
 [4, 5, 6],
 [7, 8, 9]]

Of course, ndarray can handle also a 0-D array, with 0 meaning that it is just an element:

println!("\n{}", array![2.]);
println!("Dimensions: {}", array![2.].ndim());

which correctly outputs:

[2]
Dimensions: 1

Likewise, we could go to 3D or more

let arr12 = Array::<i8, _>::ones((2, 3, 2, 2));
println!("\nMULTIDIMENSIONAL\n{}", arr12);

Guessed its output?

MULTIDIMENSIONAL
[[[[1, 1],
   [1, 1]],

  [[1, 1],
   [1, 1]],

  [[1, 1],
   [1, 1]]],


 [[[1, 1],
   [1, 1]],

  [[1, 1],
   [1, 1]],

  [[1, 1],
   [1, 1]]]]

It's a 2-elements 2 vectors, repeated 3 times, repeated 2 times; just go from right to left to unpack it from smaller to bigger (and vice-versa).

If it is still unclear, don't worry: we are here for the programming more than for the math/stats behind it.

Let's add some randomness to the mess!

We also loaded ndarray-rand into our Cargo.toml, which we briefly described earlier.

This package adds the power of the rand crate (which it re-exports as sub-module) to your ndarray ecosystem.

In order to see some examples, let's add the following in the use section of our src/main.rs

use ndarray_rand::{RandomExt, SamplingStrategy};
use ndarray_rand::rand_distr::Uniform;

Then we can get an array of shape (5, 2), for example, filled with a uniform distribution between 1 and 10 (floats, though):

let arr13 = Array::random((2, 5), Uniform::new(0., 10.));
    println!("{:5.2}", arr13);

Which results, for example, in:

[[ 2.04,  0.15,  6.66,  3.06,  0.91],
 [ 8.18,  6.08,  6.99,  4.45,  5.27]]

Results should vary at each run, being the distribution (pseudo)random.

We can also "pick" data from an array (sampling) in the following way:

let arr14 = array![1., 2., 3., 4., 5., 6.];
let arr15 = arr14.sample_axis(Axis(0), 2, SamplingStrategy::WithoutReplacement);
println!("\nSampling from:\t{}\nTwo elements:\t{}", arr14, arr15);

Which may result in:

Sampling from:  [1, 2, 3, 4, 5, 6]
Two elements:   [4, 2]

Let me show another way of sampling, which involves the use of the rand crate and the creation of an array from a vector:

We first need the following added to the use section:

use ndarray_rand::rand as rand;
use rand::seq::IteratorRandom;

So we use the rand crate as re-exported by ndarray-rand.

Then we can do the following (example in the rand docs, adapted):

let mut rng = rand::thread_rng();
let faces = "😀😎😐😕😠😢";
let arr16 = Array::from_shape_vec((2, 2), faces.chars().choose_multiple(&mut rng, 4)).unwrap();
println!("\nSampling from:\t{}", faces);
println!("Elements:\n{}", arr16);

We define the thread_rng to be used first, then we set a string containing the emoji we want to select.

Then we create an array from a vector, giving a shape. The shape we chose is (2, 2), but the vector is created using a particular IteratorRandom, i.e., choose_multiple, extracting 4 elements (chars) at random from the string.

The output is obvious:

Sampling from:  😀😎😐😕😠😢
Elements:
[[😀, 😎],
 [😢, 😠]]

Beware though not to over-sample, otherwise choose_multiple will simply panic.
Instead, Array::from_shape_vec returns a Result stating if it could create an array or not (Result which we simply unwrap).

Let's do some stats and visualize something, shall we?

Before introducing visualization, let's introduce the crate ndarray-stats, actually, also the crate noisy_float which is a must when using ndarray-stats.

First of all, we start with a Standard Normal Distribution, randomly created.

First we add:

use ndarray_rand::rand_distr::{Uniform, StandardNormal};

in its proper place, then:

let arr17 = Array::<f64, _>::random_using((10000,2), StandardNormal, &mut rand::thread_rng());

This way we have a 2D array with 10,000 couples of elements

Then we add to the use section also the imports we need to do statistics:

use ndarray_stats::HistogramExt;
use ndarray_stats::histogram::{strategies::Sqrt, GridBuilder};
use noisy_float::types::{N64, n64};

Now we need to transform each element from float into a noisy float; I will not go into explaining a noisy float, just consider it as a float that can't silently fail (be a NaN); besides this way it is order-able, which is what is needed by ndarray-stats to create an histogram.

In order to perform by value an operation on each element of the ndarray, we will use the function mapv() which is akin to the standard map() for iterators.

let data = arr17.mapv(|e| n64(e));

At this point, we can create a grid for our histogram (a grid is needed to divide the data into bins); we try to infer the best way, using the strategies::Sqrt (a strategy used by many programs, including MS Excel):

let grid = GridBuilder::<Sqrt<N64>>::from_array(&data).unwrap().build();

Now that we have a grid, that is, a way to divide our raw data to prepare our histogram, we can create such histogram:

let histogram = data.histogram(grid);

In order to get the underlying counts matrix, we can simply state:

let histogram_matrix = histogram.counts();

The count matrix just states how many elements are present in each bin and each height, in the grid.

Ok, now we have a histogram... but how could we visualize it?
Well, before visualizing our data we should prepare it for visualization.

The problem we face is that we have the counts of a grid, but to plot it we should really have a number of bin and all elements in that bin, meaning, we should sum vertically all elements.

In order to do so, we need to sum on axis(0) of the ndarray:

let data = histogram_matrix.sum_axis(Axis(0));

Now we have a 1D ndarray containing all the sums of the grid. At this point we can establish that each sum is a different bin, and enumerate them. We will transform it all to a vector of tuples, in order to prepare it for the visualization tool, where the first element of the tuple is the number of bin, and the second is the height of the bin.

let his_data: Vec<(f32, f32)> = data.iter().enumerate().map(|(e, i)| (e as f32, *i as f32) ).collect();

Remember: this is just a hoax dataset, based on a pseudorandom generator of a normal distribution (i.e., a Gaussian distribution centered in 0.0, with radius approx. 1). Still, we should see a rough Gaussian on a histogram.

DataViz

In order to visualize things we will use poloto, which is one of many plotting crates for Rust.

It is a simple one, meaning we do not need many lines of code to have something to see on our screen.

We will not import it in the use section, because it is very simple. Let me explain how to plot a histogram in three steps:

Step one - create a file to store our graph:

let file = std::fs::File::create("standard_normal_hist.svg").unwrap();

Step two - create a histogram out of the data:

let mut graph = poloto::plot("Histogram", "x", "y");
graph.histogram("Stand.Norm.Dist.", his_data).xmarker(0).ymarker(0);

We create a Plotter object, assigning it a title, and legend for each axis.
Then, we plot our histogram on it, assigning the title in the legend ("Stand.Norm.Dist.").

Step three - write the graph on disk:

graph.simple_theme(poloto::upgrade_write(file));

As simple as that!

Let's admire our work of (random) art:

OK, let's try something different: let's view our graph as a scatter plot. Since our hoax data is a Standard Normal Distribution, if we have N pairs of coordinates, the scatter plot should be like a cloud centered on the 0,0 coordinates.

Let's visualize it!

let arr18 = Array::<f64, _>::random_using((300, 2), StandardNormal, &mut rand::thread_rng());

let data:  Vec<(f64, f64)> = arr18.axis_iter(Axis(0)).map(|e| {
    let v = e.to_vec();
    (v[0], v[1])
}).collect();

We created 300 pairs of random numbered centered around (0, 0), according to a Standard Normal Distribution.

Then we transformed that array to a Vec<(f64, f64)>, because the poloto library only graphs [f64; 2] or whatever can be converted to a AsF64.

We will add also two lines to show the center of our graph:

let x_line = [[-3,0], [3,0]];
let y_line = [[0,-3], [0, 3]];

Next we create a file, plot, and save, just as we did for the histogram:

let file = std::fs::File::create("standard_normal_scatter.svg").unwrap(); // create file on disk

let mut graph = poloto::plot("Scatter Plot", "x", "y"); // create graph
graph.line("", &x_line);
graph.line("", &y_line);
graph.scatter("Stand.Norm.Dist.", data).ymarker(0);

graph.simple_theme(poloto::upgrade_write(file));

That's it! We can admire our random creation now:

Conclusion

I think this should wrap it up for today.

We saw how to use ndarray (in a basic form), and how it differs from Rust arrays and vectors.

We saw also some of its companion crates that complete the ecosystem, to provide randomness and some statistic feats.
We saw also a way to plot graphs with data, showing how to plot a histogram, a scatter plot, and some lines.

I hope this will be a good starting point to delve deeper into the use of Rust for Data Science.

That's all folks for today, see you next time!

Rust GUI: Introduction, a.k.a. the state of Rust GUI libraries (As of January 2021)

Davide Del Papa — Mon, 18 Jan 2021 17:07:07 +0000

[Photo by Kelly Sikkema on Unsplash, modified (cropped)]

This article follows up on a discussion. Please share your experience there, I'd gladly hear about it!

Which Rust crate to use as GUI framework right now (Jan 2021)?

Davide Del Papa ・ Jan 16 '21 ・ 1 min read

#discuss #rust

Introduction

Some months ago I was surveying a little the state of GUI in Rust. Let me tell you, the quest has been horrible.

Starting off some searches on internet, apart some questions on Reddit and other sites, you get some (very old) articles.

What’s the state of Rust GUIs?

Sep 19 '19 Author: [deleted]

Rust has always seemed super interesting to me since learning of its existence a few months ago. However one thing that turned me off at the time was the lack of (structured) GUI bindings for cross platform devices. But fast forward a few months, is there a good GUI library to use that can make “complex” applications? Or maybe a…

See Full Post

Old and stale.

The only guide you get at the end of the day (referenced by all) is the site Are We GUI Yet which is not helpful at all.

areweguiyet / areweguiyet

A website built for the Rust community

Readme

Want to find crates for GUI in Rust? Then you've come to the right place!

Status

This site is maintained as best as possible. The next steps likely involve replacing it with an automated system more like lib.rs.

CI runs weekly to update crate information from crates.io, if it is not overriden by the crate's configuration in this repo.

What is this?

Companion website to arewegameyet arewewebyet, and arewelearningyet.

Contributing

To make it easy for people (hey, that's you! 😊) to contribute, AreWeGuiYet uses a custom Rust CLI. It's currently a work in progress and is a little rough around the edges.

The workflow:

fork AreWeGuiYet
clone your fork
cd to the CLI directory (cli) (it currently uses relative paths 😬)
Build and run the CLI
- Usage: cargo run -- [--clean] <command> [flags]
- Help: cargo run -- help
When you're done…

View on GitHub

It seems that AreWeGUIYet has not been updated since 2019, and the interface does not help in the least to search for a suitable library. The only tags it has is on the kind of implementations the crates have. Not many articles, not a useful tutorial, no understanding about the status of the crates that are showcased there.

Some featured crates seem pretty rough, some more advanced... but there's no way to know it other than trying each and every one.

Oh.
My.

And I did install some, but the results were a disaster, because at least the ones I tried sucked a lot.

Then, over the summer I found an article by boringcactus. They had much my same experience, but I realized that I actually managed to make many more things to work than they did...

Flash forward to early November. Here I was, trying again the old way. I was serious with my intention to try each and every crate in the list.

This time around I got even luckier. At least I did not only succeeded in make some libraries to work, I actually got material to write some tutorials to help others.

Here I'll wet your appetite: there's more to come!

Disclaimers

I only tried the following on my Linux laptop: sorry, I do not own a Windows or a Mac!
I usually employ cargo add from cargo edit (to install it: cargo install cargo-edit), but you can add the dependency straight to Cargo.toml
I tried to make the crates work in every possible way, and I meant it. I even patched them locally, and even submitted some issues or even a PR. I wanted to honestly do my homework

Summary Table

Below a summary of the crates I tried, with the status I found them in:

Status	Name		Notes
Working	Druid	Review	It relies on piet 2D graphic library; on Linux that means GTK/Cairo 2D primitives
	FLTK	Review	FLTK for Rust
	GTK+	Review	Official GTK+ Rust support
	Iced	Review	Elm Inspired
	IUI	Review	Based on libui
	OrbTK	Review	Even if it is designed for Redox, it still works on other systems
	QMetaObject	Review	QT based: it relies heavily on QML
	Relm	Review	Elm-inspired, GTK improvement
	Sciter	Review	Bindings to Sciter, a commercial Library
	Tauri	Review	This is a different beast altogether: it transforms a web app to a desktop app, while adding the possibility to interface with Rust
	VGTK	Review	Built on top of GTK, and Elm-inspired
Other/Could not try	Conrod	Review	The examples work. How to build a GUI is still a mystery though.
	ImGui	Review	Same thing as Conrod, no way to understand how it works, besides the examples
	Core-Foundation	Review	Could not try: I do not have a Mac
	LittlevGL	Review	Could not try: it runs on embedded systems
	kas	Review	Could not try: I don't have Vulkan hardware, and the GTK backend is not working at all
Not Working	Azul	Review	Based on WebRender. I tried many times over to make it work... It refuses!
	QT_Widgets	Review	There's a small issue, but it does not work until it is solved

There are also two entries that I excluded completely, because I do not think they belong to Rust GUIs: WebRender and Rust-QT-Binding-Generator. Tauri almost got kicked out as well, but it stayed in, since it is another beast altogether (because it is a bridge between technologies, more than between languages as Rust-QT-Binding-Generator is).

Working

Druid

One of the crates I could not make to work the first time around (I don't remember why), but in reality Druid works like a charm now.
It relies on piet which is a 2D graphic library. On Linux it wraps GTK3 and its cairo 2D primitives, so check out all the requirements needed on your distro.
It has also a web based render engine, and it uses wasm and wasm-pack.

Let's give it a try.

cargo new rust-ui-druid
cd rust-ui-druid
cargo add druid

Then we can set up our first app in src/main.rs:

use druid::widget::{Button, Flex, Label};
use druid::{AppLauncher, LocalizedString, PlatformError, Widget, WidgetExt, WindowDesc, Data};

#[derive(Clone, Data)]
struct Counter(i32);

fn main() -> Result<(), PlatformError> {
    // Window builder. We set title and size
    let main_window = WindowDesc::new(ui_builder)
        .title("Hello, Druid!")
        .window_size((200.0, 100.0));

    // Data to be used in the app (=state)
    let data: Counter = Counter(0);

    // Run the app
    AppLauncher::with_window(main_window)
        .use_simple_logger() // Neat!
        .launch(data)
}

fn ui_builder() -> impl Widget<Counter> {
    // The label text will be computed dynamically based on the current locale and count
    let text = LocalizedString::new("hello-counter")
        .with_arg("count", |data: &Counter, _env| (*data).0.into());
    let label = Label::new(text).padding(5.0).center();

    // Two buttons with on_click callback
    let button_plus = Button::new("+1")
        .on_click(|_ctx, data: &mut Counter, _env| (*data).0 += 1)
        .padding(5.0);
    let button_minus = Button::new("-1")
        .on_click(|_ctx, data: &mut Counter, _env| (*data).0 -= 1)
        .padding(5.0);

    // Container for the two buttons
    let flex = Flex::row()
        .with_child(button_plus)
        .with_spacer(1.0)
        .with_child(button_minus);

    // Container for the whole UI
    Flex::column()
        .with_child(label)
        .with_child(flex)
}

Druid is pretty data-driven, so you see that widgets implement data-types: they are not a type unto themselves. That explains why a Widget type has to be declared as Widget<T>. We notice also that Druid employs the constructor pattern a lot.

Code notes:

#[derive(Clone, Data)]
struct Counter(i32);

We create a custom data structure to employ as our app's state. It has to derive druid::Data.

fn main() has to return a Result<(), PlatformError>, because the AppLauncher might fail.

Inside main() we create a new main widow descriptor WindowDesc out of a widget we'll create with the function ui_builder(). We set title and state of the main window.

We init the custom state (Data in druid's jargon), and we pass the window and the state to the AppLauncher, which will manage the app's cycle for us.

Notice that Druid implements a simple logger to the stderr, which I think it's a neat function for debugging.

Inside the fn ui_builder() we first create a localized string (LocalizedString), which renders a translatable text. Also this is a neat function, to have localization embedded in the regular flow of development. We assign the "hello-counter" key to it; since this is bundled as a default (for example's purpose) the translation will be automatically created for us, according to the locale (by now only English, French and German). we assign this localized string to a label (we set the center position and a padding to it).

The we create two buttons, one to increase and the other to decrease our state counter, with a callback on the on_click() event. The state will be increased (decreased), and Druid will take care to update the interface to reflect the state for us (no need to signal to the label to update its text, it's Druid's duty... Very nice!)

We create a Flex which is a container, and we stack the two button horizontally, with a space in between.

Then we return another Flex where we stack vertically the label and the Flex that contains the buttons. This is the UI that our window descriptor takes as argument.

We can now run our first Druid application.

Example Repo:

davidedelpapa / rust-ui-druid

Rust UI Rundown: Druid

Code for part of rust-ui-rundown article.

View on GitHub

Back to Summary

FLTK

Next in the list is FLTK. The first time around, I admit that I didn't even consider it: having a little C/C++ background I have actually used FLTK sometime before and, let me tell you, it's quite "complicated", and with poor results. It is not feature filled as wxWidgets or QT (it's much more bare-bones actually), but still it manages to have a way in which you have to code that... ugh! Well, I didn't even consider it because of my negative experiences in the past. However, now I'm told that FLTK has come a long way since the times I was using it in C++, so this should teach me something about having prejudices.

In fact, this time I was going to try each crate in the list, and when the FLTK bindigs turn came, I was fully blown away by this crate as soon as I gave it a try: I fell in love with it! Somehow the author managed to take away the complexity of writing a FLTK interface, and made it Rust-y (read it with a sex-y voice please!). I mean, it feels as if it was only Rust, no bindings whatsoever involved. It clearly does not feel as a wrapper, around a FFI wrapper, around a C library (too many chinese boxes I reckon), as many crates that bind C libraries (try one of the QT crates and then come beck here imploring!).
Instead, it feels like true Rust native. In order to do so, sometimes it wraps around widgets in a different way than the underlying FLTK libs. But this is really nice, I found out.

Like Druid, FLTK employs the constructor pattern a lot.

As first thing, let's check (and in case, fix), FLTK's dependencies:

sudo apt-get install libx11-dev libxext-dev libxft-dev libxinerama-dev libxcursor-dev libxrender-dev libxfixes-dev libpango1.0-dev libgl1-mesa-dev libglu1-mesa-dev

Then, we can start a new project and declare FLTK dependency:

cargo new rust-ui-fltk
cd rust-ui-fltk
cargo add fltk

Let's take a look at the src/main.rs:

use fltk::{app::*, button::*, frame::*, window::*};

fn main() {
    let app = App::default();
    let mut wind = Window::new(100, 100, 400, 300, "Hello, FLTK!");
    let mut frame = Frame::new(0, 0, 400, 200, "Boring label");
    let mut but = Button::new(160, 210, 80, 40, "Click me!");

    wind.end();
    wind.show();

    // Remember: Callbacks after initializing the interface
    but.set_callback(move || frame.set_label("Hello, World!"));

    app.run().unwrap();
}

We set the App with it's defaults, then in order to start the Window, we specify X,Y position and width,height dimensions, plus the title; then we create a Frame (equivalent of FLTK Box), again with position and dimensions, plus a label; finally a button (pos., dim., label as well).

We did not employ the constructor pattern here, but we could have done the following with the button, for example:

let mut but = Button::default()
    .with_pos(160, 210)
    .with_size(80, 40)
    .with_label("Click me!");

Which is equivalent to the above Button::new(160, 210, 80, 40, "Click me!") initializing method.

Once the UI is done, we finalize the UI (with .end()), then we show the window(with .show()).

Callbacks are to be set once the UI is finalized; so we set a callback to the button (it gets called on the click event), and in its closure we change the label of the frame.

At the end we just run the app.

Maybe you didn't realize, but this is also maybe the simplest of the example here present, yet it is fully functional!

This crate is very promising: the author even manged to use it on the Android system.

Example Repo:

davidedelpapa / rust-ui-fltk

Rust UI Rundown: FLTK

Code for part of rust-ui-rundown article.

View on GitHub

Back to Summary

GTK

Official GTK bindings, this should be the go to crate for "serious" projects. That said, please be prepared for a non ergonomic experience. You know, this is a full featured crate, binding to one of the 3 most humongous GUI libraries out there, so it is totally fitting that it has some complexity, as the full control that it brings is much bigger than any "simplistic" other project.

In fact, there are other crates that bind to GTK, and they all try to simplify it, but at the expense of full control. It's just a trade off.

That said, I have to say, the Rust bindings to GTK are much more ergonomic than the C/C++/c#. I think there's something in Rust that makes many implementations much more ergonomic than their C counterpart. Don't expect the treats fltk provides though; let's say it's a gracious compromise.

The project gives also the possibility to use Glade and its XML based interface descriptor.

Time to start off:

cargo new rust-ui-gtk
cd rust-ui-gtk
cargo add gtk --features=v3_16
cargo add gio --features=v2_44

Now, let's write our src/main.rs

use gtk::prelude::*;
use gio::prelude::*;
use gtk::{Application, ApplicationWindow, Box, Button, Label};

fn main() {
    let application = Application::new(
        Some("com.github.rust-ui-rundown.rust-ui-gtk"),
        Default::default(),
    ).expect("failed to initialize GTK application");

    application.connect_activate(|app| {
        let window = ApplicationWindow::new(app);
        window.set_title("Hello, GTK+!");
        window.set_default_size(350, 70);

        let container = Box::new(gtk::Orientation::Vertical, 10);

        let label = Label::new(None);
        let button = Button::with_label("Click me!");

        container.add(&label);
        container.add(&button);
        window.add(&container);

        button.connect_clicked(move |_| {
            &label.set_label("Hello, World!");
        });

        window.show_all();
    });

    application.run(&[]);
}

We create first an Application. We have to pass to it an identifier (an Option wrapped str) and the application's flags. We are passing to it the default ones.

Next we apply the method connect_activate which creates the UI in a closure. In this closure we declare a window for the app (ApplicationWindow), setting title and default dimensions. Then we create a Box container with vertical orientation and spacing.

We set a label, with no text (with None) and a button. We add these to the container; then we add the container itself to the window.

Next, we declare a callback for our button, with a closure that sets the label text, once the button is clicked.

We end the closure of connect_activate() by showing all widgets. Finally, we run the application.

The program works as intended, and at this stage is not even much too complex to create simple GUIs like this.

Example Repo:

davidedelpapa / rust-ui-gtk

Rust UI Rundown: GTK

Code for part of rust-ui-rundown article.

View on GitHub

Back to Summary

Iced

A cross-platform, elm inspired framework, Iced is a good small solution. The Elm like architecture has been used in many Rust projects already (think Yew or Seed). Like Druid, Iced is data centered.

The first time around I could not make it run, because I do not have Vulkan (and I made a mess with some tricks trying to install it: I do not have a compatible hardware). Since then, though, Iced has got a new OpenGL back-end through glow; the problem is, it is not yet on the crates.io version, so I needed to add it thorugh the GitHub repo:

cargo new rust-ui-iced
cd rust-ui-iced
cargo add iced --git "https://github.com/hecrj/iced.git" --features glow

And now, let's head to the src/main.rs:

use iced::{Element, Sandbox, Settings, Text};

struct MyApp;

impl Sandbox for MyApp {
    type Message = ();

    fn new() -> Self {
        MyApp
    }

    fn title(&self) -> String {
        String::from("Hello, Iced")
    }

    fn update(&mut self, _message: Self::Message) {}

    fn view(&mut self) -> Element<Self::Message> {
        Text::new("Hello, world!").into()
    }
}

pub fn main() -> iced::Result {
    MyApp::run(Settings::default())
}

This example is a bit simplified. We need to declare a struct that we need to impl as an app. In this case it is a Sandboxed type of app, that is more simplified than a regular app (and with less customizing available).

The app has to impl several functions that will be called during the application cycle:

new() to init the app
title() to assign its title (it can be dynamic: neat!)
update() to check and react to the app messages (given by the Message type, but in this case its an empty object ()). Here we have nothing to react to.
view() to render the app graphics part (the UI), in this case a simple text that does nothing but stand still.

We init the App, running it on main() with the default options.

This is how it looks like when run.

Example Repo:

davidedelpapa / rust-ui-iced

Rust UI Rundown: Iced

Code for part of rust-ui-rundown article.

View on GitHub

Back to Summary

IUI

IUI is a cross platform wrapper for libui, which in turns uses native frameworks: the usual GTK+, cocoa, and Win32API.

It is a simple yet very usable framework, at least for small projects. Let's see it with an example.

cargo new rust-ui-iui
cd rust-ui-iui
cargo add iui

In the src/main.rs:

use iui::prelude::*;
use iui::controls::{Label, Button, VerticalBox};
use std::rc::Rc;
use std::cell::RefCell;

struct State {
    label: String,
}

fn main() {
    // Initialize the UI and State
    let ui = UI::init().expect("Couldn't initialize UI library");
    let state = Rc::new(RefCell::new(State { label: "".into() }));

    // Create a window into which controls can be placed
    let mut win = Window::new(&ui, "Hello, IUI!", 200, 100, WindowType::NoMenubar);

    // Create a vertical layout to hold the controls
    let mut vbox = VerticalBox::new(&ui);
    vbox.set_padded(&ui, true);

    // Create a new label.
    let label = Label::new(&ui, "");

    // Create a button and its callback
    let mut button = Button::new(&ui, "Click me!");
    button.on_clicked(&ui, {
        let state = state.clone();
        move |_| {
            state.borrow_mut().label = "Hello, world".to_owned();
        }
    });

    // Adding controls to the box, and box to window
    vbox.append(&ui, label.clone(), LayoutStrategy::Stretchy);
    vbox.append(&ui, button.clone(), LayoutStrategy::Compact);

    win.set_child(&ui, vbox);

    // Show the window
    win.show(&ui);

    // Run the application
    let mut event_loop = ui.event_loop();
    event_loop.on_tick(&ui, {
        let ui = ui.clone();
        let mut ui_label = label.clone();
        move || {
            let state = state.borrow();

            // Update all the labels
            ui_label.set_text(&ui, &format!("{}", state.label));
        }
    });
    event_loop.run(&ui);
}

We first define a struct to hold the global state, then initialize it as a RefCell, to clone safely.

We initialize a window, with some settings, and a vertical box. We then initialize two controls: a label and a button, with its callback. Once clicked, the button changes the global state, in order to update the text label.

We then add the controls to the layout, and the layout to the window. Up to this point it works mostly as any other UI framework

When running the app, there's a little difference: we have to manage the refreshes with the on_tick() callback in the event loop.
It is conceptually similar to the MVC pattern, however, we insert our logic inside the event loop itself. This means we have to centralize all the updating of the app in one function.

This means that in order to decouple the refresh from the cycle we would need to create a function for each component, then call it in sequence in the event loop on_tick.
This is not a problem per se, but it must be considered when architecting the apps.

On the general side, I find IUI quite simple, yet usable. ~~It is a pity that its development seems halted.~~ EDIT: Good news! As you can see in the comments, the development on this library has not halted at all, it was just slowed down by the underlying C lib.

Example Repo:

davidedelpapa / rust-ui-iui

Rust UI Rundown: IUI

Code for part of rust-ui-rundown article.

View on GitHub

Back to Summary

OrbTK

orbtk is the base of the Redox Operative System widgets. It can be used also on other systems (even Android is on the plate, but the support is not yet completed).
I do not know if it's my configuration, but sometimes it feels slow. Compilation too takes a long time, even for small changes, and it seems it recompiles quite few things every time.

Remember to install xkb and wayland as dependencies:

sudo apt install libxkbcommon-dev libwayland-dev

Let's get down to business.

cargo new rust-ui-orbtk
cd rust-ui-orbtk
cargo add orbtk --git="https://github.com/redox-os/orbtk.git" --branch develop

As for the src/main.rs:

use orbtk::prelude::*;

fn main() {
    orbtk::initialize();

    Application::new()
    .window(|ctx| { 
        Window::new()
            .title("Hello, OrbTk!")
            .position((100.0, 100.0))
            .size(200.0, 100.0)
            .child(
                TextBlock::new()
                    .text("Hello, World!")
                    .v_align("center")
                    .h_align("center")
                    .build(ctx)
            )
            .build(ctx)
    })
    .run();
}

It is a very small example:

first we initialize the orbtk
then we create a new Application, and we build its window;
the window method gets a closure to which the context gets passed on. Inside it we create a Window, again with a builder pattern.
for the new window we set some properties, like title, size, and position, and we declare a TextBlock as its child
the TextBlock is build with a builder pattern as well, setting the alignment (vertical and horizontal) inside the container, and its text
both TextBlock and Window take the context as parameter of the build() method, that init the widget.
the Application, which is the top-level "container", and provides the context for the contained widgets, uses a run() method, instead, in order to build and run.

Example Repo:

davidedelpapa / rust-ui-orbtk

Rust UI Rundown: OrbTK

Code for part of rust-ui-rundown article.

View on GitHub

Back to Summary

QMetaObject

QMetaObject relies on the QT Widgets, and it is written in order to support directly the QML interface language, that is a JSON like declarative language, with some JavaScript like constructs.

Needless to say, QT Widgets must be installed. But first, we need some libraries installed as well (if you do not have them already):

sudo apt install libclang-dev libsqlite3-dev
apt-get install libllvm-11-ocaml-dev libllvm11 llvm-11 llvm-11-dev llvm-11-doc llvm-11-examples llvm-11-runtime

Now we need also QT:

Download the open source versions from the QT Download Page: in the next page scroll down and Download the QT Online Installer.

Once downloaded you have to execute the script:

./qt-unified-linux-x64-4.0.1-online.run

Please install a Desktop setting.

After this, we need to export the paths:

export PATH="~/Qt/5.15.2/gcc_64/bin:$PATH"
export LD_LIBRARY_PATH="~/Qt/5.15.2/gcc_64/lib:$LD_LIBRARY_PATH"

Substitute the 5.15.2 with your actual version.

Now we can pass to the Rust side.

cargo new rust-ui-qmetaobject
cd rust-ui-qmetaobject
cargo add qmetaobject

We can now see an example main.rs adapted from the repo's README (adapted to use standard CStr actually):

use std::ffi::CStr;
use qmetaobject::*;

#[allow(non_snake_case)]
#[derive(Default, QObject)]
struct Greeter {
    base : qt_base_class!(trait QObject),
    name : qt_property!(QString; NOTIFY name_changed),
    name_changed : qt_signal!(),
    compute_greetings : qt_method!(fn compute_greetings(&self, verb : String) -> QString {
        return (verb + " " + &self.name.to_string()).into()
    })
}

fn main() {
    qml_register_type::<Greeter>(
        CStr::from_bytes_with_nul(b"Greeter\0").unwrap(),
        1,
        0,
        CStr::from_bytes_with_nul(b"Greeter\0").unwrap()
    );
    let mut engine = QmlEngine::new();
    engine.load_data(r#"
        import QtQuick 2.6; import QtQuick.Window 2.0;
        import Greeter 1.0
        Window {
            visible: true;
            title: "Hello, QMetaObject";
            Greeter { id: greeter; name: 'World'; }
            Text { anchors.centerIn: parent; text: greeter.compute_greetings('hello'); }            
        }
    "#.into());
    engine.exec();
}

In the above we create a custom class to "implement" a C++ QObject. Of course a Rust struct cannot implement a C++ object, so in order for it to work, QMetaObject needs you to derive QObject, and then specify in the base field the C++ class to inherit from, with the macro qt_base_class!(trait QObject).
In the struct you can then add any custom field, besides a name that is the means by which the class can be render visible to the underlying C++.
In this case we added a compute_greetings which is rendered as a QT Method with the macro qt_method!() which takes a closure.

In main() we need to register our custom struct with qml_register_type which takes a uri, a version major and minor (in this case 1.0 therefore 1,0), and the name of the object (the version is needed in QML). Both uri and name have to be passed as C strings, in this case using std::ffi::CStr and the method from_bytes_with_nul; the null terminating the string (totally FFI C++ style) is rendered with \0.

Now the object is available in QML, and we can refer to it by the selected name and version (Greeter 1.0 in this case).
We can create a QmlEngine and load the QML either as a string or as a file (in our case a Rust literal string with #" ... "#). As you can see we use our Greeter and its method compute_greetings inside the QML.

Example Repo:

davidedelpapa / rust-ui-qmetaobject

Rust UI Rundown: QMetaObject

Code for part of rust-ui-rundown article.

View on GitHub

Back to Summary

Relm

A framework that aims to simplify GTK and give it a behaviour like Elm. Check gtk-rs requirements/dependencies.

In reality it does not simplify GTK, it just renders it elm-like. In fact, you need to know how to design UIs with gtk in order to use Relm. A nice thing is that Relm can use the Glade interface and descriptor as well. Another good perk is that in the examples it shows clearly how to test the interface, not a thing to underestimate!

cargo new rust-ui-relm
cd rust-ui-relm
cargo add relm relm-derive gtk

Onto src/main.rs now:

use gtk::{ Button, ButtonExt, ContainerExt, Inhibit, Label, LabelExt, Orientation, WidgetExt, Window, WindowType};
use relm::{connect, Relm, Update, Widget};
use relm_derive::Msg;

struct Model {}

#[derive(Msg)]
enum Msg {
    Hello,
    Quit,
}

#[derive(Clone)]
struct Widgets {
    lbl: Label,
    but: Button,
    window: Window,
}

#[allow(dead_code)]
struct Win {
    model: Model,
    widgets: Widgets,
}

impl Update for Win {
    type Model = Model;
    type ModelParam = ();
    type Msg = Msg;

    fn model(_: &Relm<Self>, _: ()) -> Model {
        Model {}
    }

    fn update(&mut self, event: Msg) {
        let label = &self.widgets.lbl;
        match event {
            Msg::Hello => { label.set_text("Hello, World!"); },
            Msg::Quit => gtk::main_quit(),
        }
    }
}

impl Widget for Win {
    type Root = Window;

    fn root(&self) -> Self::Root {
        self.widgets.window.clone()
    }

    fn view(relm: &Relm<Self>, model: Self::Model) -> Self {
        // Create the view using the normal GTK+ method calls.
        let window = Window::new(WindowType::Toplevel);

        let lbl = Label::new(None);
        let but = Button::with_label("Click Me");

        let vbox = gtk::Box::new(Orientation::Vertical, 0);
        vbox.add(&lbl);
        vbox.add(&but);

        window.add(&vbox);
        window.show_all();

        connect!(relm, but, connect_clicked(_), Msg::Hello);
        connect!(relm, window, connect_delete_event(_, _), return (Some(Msg::Quit), Inhibit(false)));

        Win {
            model,
            widgets: Widgets {
                lbl,
                but,
                window,
            },
        }
    }
}

fn main() {
    Win::run(()).expect("Win::run failed");
}

As you can see from the use section, gtk is not really hidden behind Relm with wrappers, but is forefront.

We need four data structures:

a struct for the Model, that holds the App's state (none in this case)
a enum Msg for the messages (callbacks), for which we derive relm_derive::Msg
a struct Widgts to hold the widgets list (we need to allow dead code, because we are not using the Model, as it has no state)
a struct Win for the main window (it holds the Model and the widgets)

For Win we impl the Update cycle, setting the model() function to create the model, and the update() function to set the behavior for each message (we match over the two messages, assigning the gtk::main_quit() when the message to Quit is fired, and setting the label's text when the Hello message is fired).

We need to impl also the Widget for our Win, setting the type of the root window (in this case single window gtk::Window). The root() function is needed to init the root window, while the view() function draws the UI, using the gtk widgets and conventions.

fn view() has to return the Widget struct initialized. We start declaring a gtk::WindowType::Toplevel window. Then we declare a label (with text = None) and a button.
We create a container and place the label and button in it, and then we place the container as the root widget of the window.
After showing the window (window.show_all()), we can set the callbacks, using the interesting Relm macro connect!. We connect the quit message of the window to the Msg::Quit, and the click of the button to the Msg::Hello.

After running the app, we have our window showing.

You can notice that the interface is quite similar to that of the base GTK app.

Example Repo:

davidedelpapa / rust-ui-relm

Rust UI Rundown: Relm

Code for part of rust-ui-rundown article.

View on GitHub

Back to Summary

Sciter

Sciter is a C-API commercial library (by Terra Informatica) used to create UIs based on web technologies. It has (amongst many others) a Rust binding, sciter-rs. There is a freeware version that we can use, and it seems that it is possible to use it also in commercial software. The only clause is to include somewhere, maybe in an about section, the following:

This Application (or Component) uses Sciter Engine (http://sciter.com/), copyright Terra Informatica Software, Inc.

The other caveat is that the executable may send diagnostic data to one of Terra Informatica 's servers. They are very clear that it may, and maybe (for what I read) it's just diagnostic (it should not infringe the EU protection laws in matters of personal data...). Anyway, the important thing is that you are aware.

By the way, between September and Octobr 2020 the author has campaigned on Kikstarter in order to raise funds to open-source the project. The campaign ended and the goal was not reached, but the author started to disclose some part of the code replacing the Javascript engine, with a BSD 3-clause license, found on github.com/c-smile/sciter-js-sdk. It seems all very promising.

Let's get down to business...

First we need to download the sdk from the sdk download page and extract it. Let's copy in a folder accessible in your PATH the libsciter-gtk.so found in bin.lnx/x64.

If it's not installed we need to install the GTK development files as well

sudo apt-get install libgtk-3-dev

And now, for the Rust part.

cargo new rust-ui-sciter
cd rust-ui-sciter
cargo add sciter-rs

Now for our src/main.rs:

use std::fs;
use std::path::PathBuf;

use sciter;

fn main() {
    let mut frame = sciter::Window::new();
    let html_file_path = PathBuf::from("./app.html");
    let html_file = fs::canonicalize(&html_file_path).unwrap();

    frame.load_file(html_file.to_str().unwrap());
    frame.run_app();
}

Notes:

We create a new Window frame with sciter::Window::new();
in order to use the .load_file() we have to pass to it the absolute path of the file .html to load (or a URL of an online resource). That is why we went to some lenghts to get a PathBuf and canonicalize it.
At the end we just run the app with run_app()

Let's see the content of app.html (to be put at the root of the project):

<html>
  <head>
    <title>Hello, Sciter</title>

    <script type="text/tiscript">
      $(button#click).on("click", function() {
        $(h1#label).$append("Hello, world");
      });
    </script>
  </head>
  <body>

    <h1 #label></h1>
    <button #click>Click me!</button>

  </body>
</html>

It is easy enough. By the way, we did not explore the interoperability between Rust and the HTML, and the TIscript (the Javascript used in Sciter), but of course it is possible (just a little more complex)

Example Repo:

davidedelpapa / rust-ui-sciter

Rust UI Rundown: Sciter

Code for part of rust-ui-rundown article.

View on GitHub

Back to Summary

Tauri

Getting into some heavy bindings (hevier maybe than even Sciter). Tauri lets you give a Desktop GUI to a web based project (HTML, CSS, and Javascript). What is it doing in this list, then? Legitimate question, and in fact I was tempted to kick it out, just like Rust-QT-Binding-Generator. However, there are two considerations in order here:

Tauri bridges the web world to the desktop using Rust, and in fact it allows to use the JavaScript just to give the Graphical side of GUI (exactly as Rust-QT-Binding-Generator uses QML, and this one stayed in the list)
Tauri bridges two technologies, web and desktop, with Rust as the man-in-the-middle (no security theats involved... maybe!). And since Rust has a good permeation inside the web world with WASM, indeed you start to see how Tauri can be beneficial in its own right as a GUI option (Tauri works well also with Yew, and the likes of it, meaning there can be more than one level of Rust integration)

We'll use Tauri in conjunction with Vue, so you have to have a node/npm/yarn environment first.
EDIT: nodejs is not required per se for the project to be ported (it could be just HTML/CSS/JS), but for now it is needed for the CLI, and in future release there's a plan to provide also a pure Rust CLI.

If you do not have already the Vue cli installed:

yarn global add @vue/cli @vue/cli-service-global

Now let's install also the Rust counterpart:

cargo install tauri-bundler

And finally let's create our project (with Vue this time!!!)

vue create rust-ui-tauri
cd rust-ui-tauri
vue add tauri

With vue add tauri we take care of the Rust part of the project. Wee have to answer some questions like app name (you can leave the default), and Window title.

Then we can test everything with:

yarn tauri:serve

We will see the default Vue homepage, inside a desktop window!

Now let's write some code, shall we?

Vue Side

src/ is taken by Vue, while src-tauri/ is the Rust root.

In src/components/ we add another .vue file besides HelloWorld.vue which is already there. We call it RustButton.vue:

<template>
    <div>
        <h1>{{ msg }}</h1>
        <button @click="call_rust">
            Click Me!
        </button>
    </div>
</template>
<script>
import { promisified } from 'tauri/api/tauri'
export default {
  name: 'RustButton',
  methods: {
    call_rust() {
        promisified({
            cmd: 'getResponse',
            payload: {
                state: 1
            }
        }).then(response => {
            // do something with the Ok() response
            const { message } = response;
            this.msg_set = message;
        }).catch(error => {
            // do something with the Err() string
            console.log(error);
        })
        console.log('Rust invoked with Promisified!');
    }
  },
  data: function () {
    return {
      msg: ''
    }
  },
  computed: {
    msg_set: {
        set: function (newValue) {
        this.msg = newValue
        },
        get: function () {
            return this.msg
        },
    }
  }
};
</script>

There could be an optional <style> part, but we do not care for this example.

The <template> contains the rendered part, the <script> the logic.

In the <template> we set an <h1> that will display a variable's value (double brackets as handlebars). We have also a button with the @click property that will cull a custom function.

In the <script> part we import promisified from tauri to use the interface with Rust, and we export a default object with the custom method call_rust() which is called by the button. This method in turn calls a Rust function getResponse with a payload object (it is there just to show the interaction between Rust and JS). This is achieved with promisified which returns a JS promise that we can consume with .then() (setting the msg data to the response of Rust with a custom computed setter). This will be called when the Rust answer comes, only if the answer is a Result::Ok; if it is a Result::Err we can catch the error with .catch().

As you can see this is a one-to-one match of a Rust function that returns a Result<T, E>. T must be serialized, while Tauri takes care of the error with the crate anyhow (for which we will implement a custom error, just because...)

There's also another JS function that can call Rust, invoke, but is more suitable for a one-way communication with Rust.

As for the rest of Vue, we just need to modify src/App.vue to call our custom component:

<template>
  <div id="app">
    <img alt="Vue logo" src="./assets/logo.png">
    <br />
    <RustButton msg=""/>
  </div>
</template>

<script>
import RustButton from './components/RustButton.vue'

export default {
  name: 'App',
  components: {
    RustButton
  }
}
</script>

The <style> part we can leave as is.

In practice in the <template>, instead of calling <HelloWorld> we call our custom component <RustButton> with an empty msg property. We need to import it in the </script>, of course, and export it as a custom component in the default object.

And with this we took care of the Vue side.

Rust Side

The Rust side of the force is very strong, as usual... sorry, I mean: it's easy to set everything since Tauri already did some scaffolding for us.

Inside src-tauri we have the usual Rust crate root, with Cargo.toml, the .lock, even a rustfmt.toml (I set the indentation to 4 spaces instead of the default 2, :-) )
There's also a configuration file for Tauri in json.

What we are interested in is the src/cmd.rs. Here we need to put some custom data structures to interface with JS, namely the Cmd itself (which is an enum), that declares the data for our custom function getResponse that we set in JS, with payload, callback, and error. We have also to declare the struct Response to be sent to JS, and a struct representing the payload, which has to mimick the data we get from JS.

We'll use serde, that is already set as dependency in the Cargo.toml

use serde::{Deserialize, Serialize};

#[derive(Deserialize)]
pub struct GetResponsePayload {
    pub state: u64,
}

#[derive(Deserialize)]
#[serde(tag = "cmd", rename_all = "camelCase")]
pub enum Cmd {
    GetResponse {
        payload: GetResponsePayload,
        callback: String,
        error: String,
    },
}

#[derive(Serialize)]
pub struct Response<'a> {
    pub message: &'a str,
}

In main.rs we define a custom Error type (that's just boilerplate). We are more interested in the main() function:

fn main() {
    tauri::AppBuilder::new()
        .invoke_handler(|_webview, arg| {
            use cmd::Cmd::*;
            match serde_json::from_str(arg) {
                Err(e) => Err(e.to_string()),
                Ok(command) => {
                    match command {
                        // definitions for your custom commands from Cmd here
                        GetResponse {
                            payload,
                            callback,
                            error,
                        } => tauri::execute_promise(
                            _webview,
                            move || {
                                if payload.state != 0 {
                                    let response = cmd::Response {
                                        message: "Hello, World!",
                                    };
                                    Ok(response)
                                } else {
                                    Err(CommandError::new("State not OK").into())
                                }
                            },
                            callback,
                            error,
                        ),
                    }
                    Ok(())
                }
            }
        })
        .build()
        .run();
}

We build a Tauri App, with the builder pattern, then we use a closure to manage the interface with JS, using invoke_handler(), before build() and run().

Inside the closure we convert the json object handler and match over it: if it is Ok we match the command to see which one we got (there can be more than one invoked by the JS of course).

If it is our GetResponse, we execute the promise, that is, we send back the answer. I put an if guard on the state that we got from JS, just to show the interaction...

Now everything is set, we can proudly run our app:

Example Repo:

davidedelpapa / rust-ui-tauri

Rust UI Rundown: Tauri

Code for part of rust-ui-rundown article.

View on GitHub

Back to Summary

VGTK

VGTK: built on GTK and gtk-rs, above in the list, inspired by Elm, and its inspired Rust counterparts, with a virtualDOM of sorts, like React, and with a sort of JSX for Rust interfaces... Lots to take in at a first date... Ok let's go in to this blind date, and see if it's a love at first glance or not... or maybe if it will become a steady friendhip, why not?

We need, as for the other GTK based frameworks, a working GTK environment.

cargo new rust-ui-vgtk
cd rust-ui-vgtk
cargo add vgtk --git=https://github.com/bodil/vgtk

If we tried now to build a project from crates.io version, we would have some weird compilation error. The point is, something strange happened with gdk-pixbuf version "0.9.0", which is referenced to by vgtk "0.3.0" in crates.io. Instead, upon compilation from GitHub, those problems disappear. The only thing is that the compilations times are larger... It seems to be something connected to compiling by default also the docs, but I didn't have time to check it out better.

And now, let's take a look at our src/main.rs:

use vgtk::ext::*;
use vgtk::lib::gio::ApplicationFlags;
use vgtk::lib::gtk::*;
use vgtk::{gtk, run, Component, UpdateAction, VNode};

#[derive(Clone, Debug, Default)]
struct Model {
    msg: String,
}

#[derive(Clone, Debug)]
enum Message {
    Exit,
    UpdateLabel,
}

impl Component for Model {
    type Message = Message;
    type Properties = ();

    fn update(&mut self, msg: Self::Message) -> UpdateAction<Self> {
        match msg {
            Message::Exit => {
                vgtk::quit();
                UpdateAction::None
            },
            Message::UpdateLabel => {
                self.msg = "Hello, world!".to_owned();
                UpdateAction::Render
            }
        }
    }

    fn view(&self) -> VNode<Model> {
        gtk! {
            <Application::new_unwrap(Some("com.example.rustuivgtk"), ApplicationFlags::empty())>
                <Window border_width=20 on destroy=|_| Message::Exit>
                    <HeaderBar title="Hello VGTK!" show_close_button=true />
                        <Box spacing=10 orientation=Orientation::Vertical >
                            <Label label=self.msg.clone() />
                            <Button label="Click Me!" on clicked=|_| Message::UpdateLabel />
                        </Box>
                </Window>
            </Application>
        }
    }
}

fn main() {
    std::process::exit(run::<Model>());
}

To be honest, according to me it reminds of a fusion between VUE and Yew..., VUE for the code organization, and Yew (inspired by Elm in this) for the pretty recognizable MVC pattern (which is not a classic MVC, there's something peculiar to this that I can't put my finger on... yet).

As for the code, it is simple enough:

We have to build a model and a message system, as usual in these Elm-inspired frameworks; then we need to implement a model with an update() function to handle the messages, and a view() function to render the interface.

The model derives Default, so there's no need for initialization (which would get much more verbose).
The view() employs the macro gtk! which is like JSX, but for GTK interfaces.

The result, for you:

All in all it's not bad, the structure is clean enough, and the handling of the gtk! is neat: it seems really to be in a web based environment, and the limited testing I have done show that the framework is powerful enough. I will definitely go deeper with this framework.

Example Repo:

davidedelpapa / rust-ui-vgtk

Rust UI Rundown: VGTK

Code for part of rust-ui-rundown article.

View on GitHub

Back to Summary

Not working at all!

Azul

Azul: there was a broken dependencies. This crates is being developed, slowly so the bug might me fixed any time soon. Still, right now it is very promising, but unusable.

Back to Summary

QT_Widgets

QT_Widgets is a Rust Qt binder from Ritual, a C++ to Rust wrapping project. Not too well documented, it is a series of unsafe wrappers for the various C++ QT libraries.

I tried to make it work in a few ways, I even submitted an issue and a pull request for a bug, but as is the crate is not working. Maybe the situation will change, and I'll inform you soon.

Back to Summary

Other Issues

In fairness I have collected here some other crates that I didn't even try or that I tried but have some other issues:

Don't belong to the list according to me

Maybe I am a little too opinionated, but still:

Rust-QT-Binding-Generator

Rust-QT-Binding-Generator: it creates bindings for Rust and QT so that you can call Rust code from inside a QT interface.

The homepage says "it helps to create a Qt based GUI on top of Rust code". In reality it is not the case that you can use QT from a Rust program, but instead you have to write a QT program (in C++ and/or QML) and import the Rust code.

No way I am considering this as a Rust GUI project. It is useful in its own right, but not as a Rust GUI.

Back to Summary

WebRender

The folks at AreWeGuiYet put in the list also WebRender.

This does not belong to a GUI framework list, sorry: it is very low level! At this point we should add also the bindings for GDK, Cairo, etc...

In this I disagree: it is true you can render a GUI with WebRender (as you could with the bare cairo bindings, why not?), but this does not mean WebRender is a GUI framework.

Back to Summary

Immediate Mode "GUIs"

I have found a lot of immediate mode GUIs, which I purposely took out of the list: immediate mode GUIs belong to the gaming world, not to the Desktop Applications world.

Unless you have done a GUI in Blender's Style, that is useful also outside the realm of Graphics... at this point, let's discuss about it!

Here I present the two most used (and that are present in AreWeGUIYet, but shouldn't):

Conrod

Conrod is tied to the Piston Game Engine. Indeed it is its conception of User Interface.

There's often some dependency issue with XCB, needed by the xcb crate. In that case, you might need some or all of the following:

sudo apt-get install xcb xcb-proto libxcb-xkb-dev x11-xkb-utils libx11-xcb-dev libxcb-xrm-dev libxcb1-dev libxkbcommon-dev  libxcb-keysyms1-dev libxcb-xrm0 libxcb-shape0-dev\
libxcb-util0-dev libxcb-cursor-dev  libxkbcommon-x11-dev libxcb-xfixes0-dev

Just check what the linker complains about (remember to take off the initial "l"; so if it's "-lxcb-shape: missing", you know you need xcb-shape, found in libxcb-shape0-dev, etc...)

What works: the examples

git clone https://github.com/PistonDevelopers/conrod.git
cd conrod
cargo run --release --example all_winit_glium

The examples are found in conrod/backends/conrod_glium/examples take a look there if you are interested.

What does not work: making a simple UI by yourself.

Now, I could not reproduce any of the examples and modify it: all the examples depend on some other module that is in there, with no explanation.

There's also an unfinished official guide, but I found myself at loss nevertheless.

There is not a single/simple way of understanding what is going on, what we are required to do, and most of all, why.

What can I say? Maybe if you are in the know about Piston you swim easily in Conrod, but otherwise it seems just mumbo-jumbo to me.

Back to Summary

ImGui

imgui is a Rust binding for Dear ImGui... Oh, dear! This is the same blessed way of doing things as Conrod: a lot of boilerplate inside a folder in the examples, that even if you copy it to your own project doesn't work!

Why, I say, why don't they make all the support boilerplate inside of the project? why a stupid folder in the examples? Is it too much to ask for a working minimal example when you are just learning about a new library?

Anyway, the working examples are as follows:

git clone https://github.com/Gekkio/imgui-rs
cd imgui-rs
git submodule update --init --recursive
cd imgui-examples
cargo test
cargo run --example hello_world
cargo run --example test_window

The state of these projects is a pity, but I wonder: there are 70 contributors to this package, and the GitHub repo has 1.1k stars.

Can anybody make a stupid example, a tutorial, something for the rest of us? Please! Searching online gets results dated 2018 at best, on stuff I could not try, or even some 404 errors!!!

I would expect something, even minimal, to grasp at, from a project with 1.1k stars!

Back to Summary

Could Not Try: Core-Foundation

Maybe it's the best tool around in the Mac world, I don't know, but I could not try Core-Foundation, because I do not own a Mac.

Back to Summary

Could Not Try: LittlevGL

This one is different: LittlevGL runs on embedded systems. I could not try it, but I look forward to get a Raspberry o something similar, and play a little with Rust in embedded systems.

Back to Summary

Could Not Try: KAS

I tried with the GTK back-end, which is not working at all, but the main KAS crate employs Vulkan, for which I do not have any compatible hardware...
I could not try it out, sorry.

Currently, KAS's only drawing method is WebGPU which requires DirectX 11/12, Vulkan or Metal. In the future, there may be support for OpenGL and software rendering.

I do not have hardware support for vulkan. I tryed the GTK backend enabling Rust nightly (rustup override set nightly in the project root folder). Sadly it didn't work

Compiling kas-gtk v0.0.2
error[E0635]: unknown feature `const_vec_new`
 --> /home/<*>/.cargo/registry/src/github.com-1ecc6299db9ec823/kas-gtk-0.0.2/src/lib.rs:8:12
  |
8 | #![feature(const_vec_new)]
  |            ^^^^^^^^^^^^^

error: aborting due to previous error

I hope to see improvements on the GTK back-end, so that at least I can try it on my machine (or to see an improvement in my salary in order to start owning better machines... but I do not think that is coming around any time soon).

Back to Summary

Conclusions

I tried over the past three months a lot of different crates. Right before publishing I even made sure they are all working properly.

Some crates do work, some crated do not. In my opinion, those who work should be merit-signalled, those who don't should be helped to get to a minimal usable product.

It is a shame that in the Rust ecosystem the GUI world is so mistreated. Granted, even in other languages the situation is not simple at all, but if Rust wants to take a spot out of the niche, as a mainstream language, curating the GUI state would be largely profitable.

Hope this little work of mine can help you getting your hands dirty with Rust GUI programming.

'Till next time!

Which Rust crate to use as GUI framework right now (Jan 2021)?

Davide Del Papa — Sat, 16 Jan 2021 23:48:55 +0000

[Photo by Harpal Singh on Unsplash, modified]

I am writing a post on the subject of Rust GUI, and sadly I am realizing that no much progress has been done in this area lately.

The site AreWeGUIYet seems almost abandoned to its own fate...

Thus I am polling you guys to know which Rust crate would you recommend to use in 2021 in order to give a Rust program a nice GUI?

Dev DigitalOcean Hackathon: Geobot, a Geography Python Twitter Bot - Submission Form

Davide Del Papa — Mon, 11 Jan 2021 01:04:47 +0000

What I built

Geobot, a Geography Python Server and Twitter Bot.

Category Submission:

Program for the People

App Link

Main server: https://geobot-hcm6d.ondigitalocean.app/
The Twitter handle is: @geobotshow

Screenshots

The TwitterBot showing a location.

The API showing a bounding-box location.

The API showing a location near a point, with some Points of Interest (POI): fountains and drinkable water.

The TwitterBot showing an earthquake.

Description

The project aims to provide a platform for geographic data images and enhancements such a search of Points of Interest (POI). The server relies on a custom library that is quite extensible.

Besides the server, as a showcase, there's a TwitterBot that can show the user's location upon request, and has a service to shows location and info on recent earthquakes (data from USGS)

Link to Source Code

Geo-Server: https://github.com/davidedelpapa/geobot
TwitterBot: https://github.com/davidedelpapa/geobotshow

Permissive License

MIT for both

Background

I was always interested in geography and visualization. The point is that a map is the most packed and effective data visualization created by man, and yet everyone can read it quite profitably.

The recent years' satellite development has shown that we can combine maps with satellite images, that is, using actual images of some places, instead of mere representations (classic maps), and still map on them also some representations (points of interest, roads, color the map according to some pattern...). This demonstrates how far can the boundaries of visualization being pushed, and still obtain easily understandable results.

Besides these considerations, many think the market for end consumers geography applications is getting reaper by the day. The ecosystem to use as source is ripe enough (with free and opensource geographic datasets and imagery). Yet, there's quite a lack on the other side of the spectrum, the end customers applications: it seems as we did not yet understand how to profit of the immense power of geographic data.

This app shows an example of how to build a simple, yet extensible geographic system. In fact the server can be extended to add more endpoints, in order to exploit the power of the library, and also the twitterbot can take advantage of other aspects of the API.

Moreover, the twitterbot can be swapped for, or paired with, many other communication bots, all referring to the same GeoServer, such as a TelegrmBot, or any other bot that can be built on top of social networks or communication systems.

How I built it

The app actually uses two components. This means that there is not only a container for the main app (the server), but also one for a worker (the twitterbot).

Sadly, there are not many information on how to pair a service with a worker, so I had to find ways by exploring by myself.

At the beginning I explored ways to use directly the Python components inside a Docker image.
In fact, preparation for the Hackathon, I made some tests and a tutorial on how to deploy, through Docker images, any non supported Language. See here my article on deploying a Rust server. At the beginning in fact I was leaning on building the server in Rust, and the bot in Python.

However, after some trial and error I made it to work as intended, with two components.

The procedure though is not yet perfect; for example I could manage to put a Deploy to Do button to work correctly only with one component at a time. I did not find a way to reproduce my two components setting so far.

I also abandoned the idea of developing the server in Rust, mainly because it is still a niche language, not profitable by many people. I wanted this to be a project that many people can pick up, thinker with, extend, adapt... Of course I did not abandon completely the idea of rewriting a server in Rust, but I'm waiting also to see if it will be supported by the DigitalOcean App Platform natively.

Additional Resources/Info

Data Providers:

Mapbox: The tiles images
OpenStreetMap: PoI location
USGS: Earthquakes position and information

Useful information and algorithms:

Slippy Map Introduction: What is a slippy map? Useful for total beginners
Tiles to LongLat and viceversa: an article by OpenStreetMap with many languages implementation of the basic algorithms
Aviation Formulary: It has got many formulas, many approximation algorithms... It is a mine for geo-math

Dev DigitalOcean Hackathon: Geobot, a Geography Python Twitter Bot - Tut 03

Davide Del Papa — Mon, 11 Jan 2021 00:06:00 +0000

[Photo by Andrew Neel on Unsplash, modified(crop)]

In the previous installments we laid the foundations for our infrastructure.
It is time now to produce some maps!

Please notice that this cannot be a detailed tutorial, it is more like a quick summary of the work done, with some commentary.

Mapbox

When I first started doing web maps there were less tools and companies involved in the process. As of today many companies have come and gone, so it is difficult sometimes for an lay man to get started in geography.

That is why you have to sort of trust me in this. For this project we will not use Google Maps, although it is a very popular and trusty too. We will use Mapbox, also because even though it s less known, in the open source web map world is gaining lot of traction.

Point your browser to the Mapbox registration page if you do not yet have an account, and follow the easy instructions

After confirming your email you can go to your account page in order to generate a new token (an API key)

Once you have created a token, we need to save it on an .env file to be put inside the service repository, not the bot.

Here we did not have an .env file, so just create one

MAPBOX_TOKEN=***
MAPBOX_URL=https://api.mapbox.com/v4/mapbox.satellite

We will use the URL later on.

Now we will see how to use that token

Web Maps

There are several standards for web maps, however here we will use a not so standard slippy map, which is sort of WTMS, but it follows the standards loosely.

What we need to know is the following: the map gets rendered at different zoom levels as a mosaic, that is, a series of tiles, or square 256×256 pixel images, one besides the other. if you zoom in, each tile is subdivided in 4 tile, if you zoom out, 4 tiles are collapsed into one tile.

The zoom level 1 shows the whole world inside a single tile, at zoom level 2 the world fits neatly in 4 tiles, while at zoom level 3 there are 16 tiles to represent the whole world.

I think this is sufficient as a quick introduction to the subject matter.
However, there's still a problem: how to get locate on a map any geographic point (usually given in the latitude/longitude notation)?

There's a mathematical equation that does this, and if you want to know more, read this article by OpenStreetMap.

These are the two formulas:

def deg2num(lat_deg, lon_deg, zoom):
    lat_rad = math.radians(lat_deg)
    n = 2.0 ** zoom
    xtile = int((lon_deg + 180.0) / 360.0 * n)
    ytile = int((1.0 - math.asinh(math.tan(lat_rad)) / math.pi) / 2.0 * n)
    return (xtile, ytile)

While the reverse:

def num2deg(xtile, ytile, zoom):
    n = 2.0 ** zoom
    lon_deg = xtile / n * 360.0 - 180.0
    lat_rad = math.atan(math.sinh(math.pi * (1 - 2 * ytile / n)))
    lat_deg = math.degrees(lat_rad)
    return (lat_deg, lon_deg)

For both we need to import Math

Get a Map of a Bounding Box

Time for action!

We will do the following

Define an API interface to get a Map as an image, given a bounding box (W, N, E, S)
Retrieve the necessary tiles
Process those tiles into an image

Easy? Let's see...

First things first: Mapbox already has a static image API, that gets you an image out of a bounding box (it actually has some good advanced options).

So, why don't we use it? Well, we could use it, but we will not be able to customize much the experience for our users, let alone making this a more universal geography system.

Therefore, if it is needed as quick-fix to scaffold the structure we can use ready made functions, but if we want to squeeze out something more for the user experience, we need to go the indie way.

That said, let's go forth and create the API interface.

source venv/bin/activate
pip install urllib3 Pillow geojson overpy
pip freeze > requirements.txt

We installed the following packages:

urllib3 handles connections
Pillow is for image manipulations
geojson handle a specification of JSON called GeoJSON used for transferring geographic data as JSON (Wiki article and the Official Specification)
overpy is a tiny layer for requests to the Overass API; it allows to query the data from the OpenStreetMap

The API will be defined as follows:

@app.route('/api/bbox/<float:w>/<float:n>/<float:e>/<float:s>', methods=['GET', 'POST'])
def show_bbox(w, n, e, s):
    pass

Now we need a function to retrieve the tiles from the tile-server and one to process those tiles into a single file.

I've made a custom library that does just that. But it took me the most part of this hackathon!

The library is in the folder geobot/ of the repository. I will quickly review what each component does.
Bear in mind that this was a quick development, not everything has been documented properly.

The geo.py Geographic utilities

Here there are some classes (some dataclass actually) and helper functions to deal with the geographic coordinates (Latitude, Longitude)

LonLat represents a point as (Latitude, Longitude) coordinates
Tile represents a bounding box, with coordinates (West, North, East, South)
Tile represents a tile to be got from the tile-server

The tileget.py Interface with the tile-server

It contains a class, Tileget, that handles the tile retrieval from the tile-server

The temps.py Temporary Files and Folders Utilities

In the Python standard library there are already means to get Temporary Files and Folders ; however, here we need them temporary, but they have to get around quite a lot... We needed something different to handle our images.

The tiledraw.py Tile-to-Image Interface

Tiles from a tile-server are not only images. They are geo-referenced images, that is, they carry their geographic location information about them.

The Dtile class handles tiles that can be drawn upon. It has got a simplistic (for now) way of rendering GeoJSON on them, add a watermark for copyright notices, resize and crop, maintaining the geographic information needed even after the image manipulations.

The overpass.py OSM Data Interface for GeoJSON

There are some helper classes and functions to retrieve information from OpenStreetMap, and render it as GeoJSON.

As for now it is just a stub, but it should be more developed, in order to get some POI, Points of Interests out of the map and mark them on the images

The tiledraw.py Tile Render Engine

Here we have the utilities to download the tiles, prepare an image out of those tiles, and render it as normal image

The Working Endpoints

For now, only two endpoints are working

@app.route('/api/bbox/<float:w>/<float:n>/<float:e>/<float:s>', methods=['GET', 'POST'])

This endpoint returns a bounding box image.

@app.route('/api/point/<float:lon>/<float:lat>', methods=['GET', 'POST'])

This endpoint calculates a bounding box near the specified point and returns the image.

Testing locally, we can see that easily working.
We need to run the local gunicorn server:

gunicorn app:app

NOTE, if it is not working, maybe you need to get the environment file to be read by the virtualenv:

deactivate
echo "set -a; source $(pwd)/.env; set +a" >> venv/bin/activate
source venv/bin/activate
echo $MAPBOX_URL

When it works, in a separate shell, we ask for the file image:

curl --output file.png 'http://127.0.0.1:8000/api/bbox/14.141636/42.522977/14.184637/42.497605'

We can also ask for an image near a point, let's say, in a 30 meters radius:

curl --output file.png 'http://127.0.0.1:8000/api/point/14.141636/42.522977?near=30'

Notice that the Geobot performs an harmonious scaling, basically maintaining some of the proportions of the tile-set it retrieved according to the geographic detail needed. In this way, if a bounding-box belongs to 2 vertical tiles, you will see an image taller than higher, not a square image.

If you want to search for bounding box to try to show, I recommend visiting the following site:

http://bboxfinder.com/

Try it, and build your own queries.

Last, but not least, the GeoJSON capabilities. Both endpoints in fact can render arbitrary GeoJSON

I left a GeoJSON test file in examples/

You can use it as follows:

curl -X POST -H "Content-Type: application/json" -d @examples/fountains.geojson --output file.png 'http://127.0.0.1:8000/api/bbox/14.141636/42.522977/14.184637/42.497605?cropped=1'

Notice that adding the cropped parameter crops the image to the bounding-box, before scaling it.

The GeoJSON used was extracted with a Overpass Query from OSM data, transformed to GeoJSON and fed to the endpoint.

The same result can be obtained using the api/poi_bbox/ endpoint. This endpoint accepts some Point of Interest (PoI) names to search with Overpass inside the bounding-box.

In examples/ there's a file calld poi.json containing the query to be fed to the api/poi_bbox/ endpoint. The format is really simple: an object with a 'poi' key, and a list of names of Point of Interest:

{"poi": ["fountain", "drinking_water"]}

You can feed it to the API as such:

curl -X POST -H "Content-Type: application/json" -d @examples/poi.json --output file.png 'http://127.0.0.1:8000/api/poi_bbox/14.141636/42.522977/14.184637/42.497605'

This time the resulting image was not cropped, but the search has been done only inside the bounding-box, that is why the image covers more area (according to the tiles downloaded), but the markers are shown only for certain elements (again, only those inside the bounding-box). That is why in this setting the cropping utility works best.

Interfacing the TwitterBot

From a tweet we can get the location; we are going to exploit this in order to get a map near the user location.

Notice that the user has to have allowed beforehand the position in their Twitter interface, otherwise there will not be any information.

The information itself can be in several places, marked as coordinates. For this reason, we have to try several things. Also the information can be as a pint, or as a bounding box, according as the user specified a simple point location or a place (extended).

Besides, the information can be presented as a Geometry or otherwise... We will use a regex to extract the coordinates, and parse them.

It's long and tedious, but it must be done...

At the end, mentioning the bot in a geo-located setting works...

However, if the location is not precise (for example, selecting the city, instead than the neighborhood or a nearby Point of Interest) results in more errors than nothing

In fact, above I was hoping it showed the city, and instead it showed an arbitrary point inside the city.

This happens because the coordinates provided by Twitter are not so ideal

Here instead I put a famous local bar as location, and it got me the image all-right.

Developing some more

Just to show a little bit the power of the underlying platform, I refactored the code and added a new function.

THis new function basically checks for earthquakes through the quakefeeds library, which uses the web services provided by the USGS.

In practice it searches for the last earthquakes (last hours), for new ones. The level is set to retrieve only the significant ones, but it can be tweaked to some magnitude levels, or to get them all.

Once it retrieves the information, it creates a message with the most important points, and a link to the info on the earthquake at the USGS's site.

Then it retrieves a map centered on the epicenter with a 10km radius from the Geobot server.
Finally it posts the picture with the relevant information.

Conclusion and future developments

We have shown so far a series of capabilities of the library we've created, and the API developed so far.
However, the library allows for much more than what covered in the API.

For example:

the library is capable of customize the markers, the colors, using different icons as marker
the library can return GeoJSON in exchange for a Overpass Query (there's a more generic builder for it), or a search by PoI
the library can return the tile-sets as GeoJSON bounding boxes, useful in order to extrapolate these info while browsing maps online (to add functionalities to layers of map rendering software, as for example leaflet.js)

All these capabilities are already present in the library: it is just a matter of finding the best way to expose them with a web API.

In addition to these, there can be much more functionality to be added to the API with a minimal effort.

For example an endpoint could be created to easily search for bounding-boxes based on names (for example the name of a city, and a rough bounding-box covering it).

The bot can be further developed, either with new possibilities, or copying the same functions over to other networks or communications systems (Facebook, Telegram, Slack...)

Again, there are many possibilities for such a fast growing field.

In fact, the market for end-customer geographic web application is getting reaper and reaper by the day, and niche products can still cut a slice of shares out of bigger companies, in my honest opinion.

Dev DigitalOcean Hackathon: Geobot, a Geography Python Twitter Bot - Tut 02

Davide Del Papa — Sun, 10 Jan 2021 09:46:16 +0000

[Photo by Dulcey Lima on Unsplash, modified(crop)]

The first installment of this series we just built a phony Python app and deployed it to DO App Platform.

Today we will lay the foundations of what is to follow.

Plan of Action

As the man-month story teaches, I had some time (Christmas Holidays), and we have a project to develop. I needed a plan!
This is what happened, faithfully reported... more or less!

This was what I thought:

Well... we do not know as yet what we are building at the end, leave alone a plan!

OK, the project sounds like this: we will create a bot (in this case a Twitter Bot to keep focused just on one platform, but we could port it as well). This bot is Geography oriented, that is, it should produce maps.

The basic functioning is this: you mention the bot in Twitter, and the bot answers your tweet with a tweet of an image containing the map.

The basics is this, we can extend it at will (and we WILL).

As for the plan (roughly):

Build a server API with the same characteristics of the BOT (both to test the functionalities apart from the BOT, and to allow for composition)
Add a BOT to the server (or more than one)

We will use an incremental functions development methodology, such as that from today onward we will have always a usable server and a usable BOT at least, adding functionalities as we go.

It doesn't matter that we do not show images as yet, but it is important that we keep paired the server-BOT interface.

We need a BOT (and a Twitter Developer Account)

As per the above, we have a server that shows us a message: we need a BOT that does the same.

Let's create a new repo for this, with the usual:

mkdir geobotshow
cd geobotshow
python3 -m venv venv
curl -L -o .gitignore https://raw.githubusercontent.com/github/gitignore/master/Python.gitignore
git init

We will use tweepy for this project. First let's activate, then we install all that is needed

source venv/bin/activate
pip install tweepy requests
pip freeze > requirements.txt

Tweepy uses OAuth to authenticate to Twitter. You need up to 4 keys in order to use it. Time to get those!

To create a new twitter app for your bot, go to the twitter developer page and Apply (top right).

Then, I chose in the welcome page the hobbyist reason that... I'm building a bot!

It then asks if it's me! Well, duh!

OK, kidding, just select the country, and other options (if applicable). Next it will ask you to explain what you need the account for.

"How will you use the Twitter API or Twitter data?"

Go ahead and write your reasons!
Mine were kind of: "Create a useful geography bot" (okay, maybe I spent some few additional words for the concept to be accepted, at least 200 char!).

OK, go ahead and answer all questions. Switch off those that do not apply (such as showing tweets outside Twitter & the sharing with government entities... unless you are from the Gov, following this: in that case, I declare I have nothing to do with everything is written in this post series!!!)

After this you have to review, and to accept the agreement and submit.

At the end you should get an email confirmation to activate the developer's account.

When you do, you'll be redirected to the app creation page:

Now thou can finally Get the Keys Yeahhh!

Now you have to copy them. I suggest you create a .env file in your project, with the following:

TWITTER_API_KEY=***
TWITTER_API_SECRET_KEY=***
TWITTER_BEARER_TOKEN=***

The bearer token is better saved somewhere, even though we are not going to use it.

If you copied the .gitignore as I showed in the first tutorial, it is already ignored by git, otherwise you should add .env to your .gitignore

Now go to the app page, and edit the "App Permissions"

Set it to both Read&Write. Then save.

We need to go to the app Keys and tokens

At the bottom, we need to generate the Access token & secret.

Now we can update our .env with 2 new fields:

TWITTER_ACCESS_TOKEN=***
TWITTER_ACCESS_SECRET=***

Finally we need these variables available in the virtual environment.

We first deactivate the environment (if active), then append the load commands to the activate file itself

deactivate
echo "set -a; source $(pwd)/.env; set +a" >> venv/bin/activate

Now we can re-activate the environment and check if the variables were set

source venv/bin/activate
echo $TWITTER_API_KEY
***

You should get your API KEY printed out

Test the Tweepy Communications

We should check that everything is going well.
On the terminal get a Python shell:

python
Python 3.8.6 (default, Sep 25 2020, 09:36:53) 
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

Now we can import Tweepy and test the access:

>>> import tweepy
>>> auth = tweepy.OAuthHandler(TWITTER_API_KEY, TWITTER_API_SECRET_KEY)
>>> auth.set_access_token(TWITTER_ACCESS_TOKEN, TWITTER_ACCESS_SECRET)
>>> api = tweepy.API(auth)
>>> api.verify_credentials()

In the above, substitute the key names with the actual values (or import them from the .env).

Basically we first create a authorization object, then we set for it the access tokens.

We pass the keys to an API object, and then we use the verify_credentials() method to verify that it is working as expected.

You should see the terminal flooded with info, and that means that it is working. Towards the beginning you should get info on the real name and the screen name, but if you do not spot them among all the rest, try the following:

>>> user = api.get_user('<your-twitter-name>')
>>> print(user.screen_name)
<your-twitter-name>
>>> print(user.name)
<Your Real Name>

Substitute in the above your twitter handle inside api.get_user(), and you should see the correct info printed.

Now you can quit() the Python shell (just write that function name and press enter).

We Can Implement the BOT Now

We need a configuration file to load configurations for the Twitter bot; we call it config_tweepy.py

import tweepy
import logging
import os

logger = logging.getLogger()

def get_api():
    api_key = os.getenv("TWITTER_API_KEY")
    api_secret = os.getenv("TWITTER_API_SECRET_KEY")
    access_token = os.getenv("TWITTER_ACCESS_TOKEN")
    access_secret = os.getenv("TWITTER_ACCESS_SECRET")

    auth = tweepy.OAuthHandler(api_key, api_secret)
    auth.set_access_token(access_token, access_secret)
    # Set some useful alerts
    api = tweepy.API(auth, wait_on_rate_limit=True, 
        wait_on_rate_limit_notify=True)
    try:
        api.verify_credentials()
    except Exception as e:
        logger.error("Error connecting to the Account", exc_info=True)
        raise e
    logger.info("Connected to the API")
    return api

Now we will put it to use inside a bot called tweet.bot.py:

import time
import os
import logging
import tweepy
import requests

from config_tweepy import get_api

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger()

def check_mentions(api, since_id):
    logger.info("Retrieving mentions")
    new_since_id = since_id
    for tweet in tweepy.Cursor(api.mentions_timeline,
        since_id=since_id).items():
        new_since_id = max(tweet.id, new_since_id)
        if tweet.in_reply_to_status_id is not None:
            continue
        logger.info(f"Answering to {tweet.user.name}")
        logger.info(f"{tweet.text}")

        # getting the API response
        response = requests.get(os.getenv("API_HTTPS"))

        # reply to mention
        api.update_status(
            status=f"@{tweet.user.screen_name} {response.text}",
            in_reply_to_status_id=tweet.id,
        )
        logger.info(f"Since_id: {new_since_id}")
    return new_since_id

def main():
    api = get_api()
    since_id = int(os.getenv("BOT_SINCEID"))
    while True:
        since_id = check_mentions(api, since_id)
        logger.info("Waiting...")
        time.sleep(30)

if __name__ == "__main__":
    main()

As you can infer from the above, we need two additional env variables,

API_HTTPS=https://<appname-id>.ondigitalocean.app/
BOT_SINCEID=1

The first holds the URL of your service, to retrieve the data from (you can check that easily underneath the name of your DO App Service).

The second holds a sort of pagination of the tweets id, so that it keeps track of what it has already answered to, in order not to start always to answer from the beginning. We start with 1, and it will get automatically updated. Also check on it, since it goes on the logs: this way if the app crashes, or gets updated, we can resume from the last one, and not start back from the beginning

Time to run:

python3 tweet.bot.py

We can tweet something mentioning our bot, in order to test if it works

@geobotshow test

And after a while we should see in the console the logging of the action:

INFO:root:Retrieving mentions
INFO:root:Answering to Davide Del Papa
INFO:root:@geobotshow test 4
INFO:root:Since_id: 1342897400902508546
INFO:root:Waiting...

And it should show also in your timeline

I suggest to save the Since_id and to substitute to the script's own one, so that each time it starts again the script will not attempt to answer to old mentions-

I suggest also to cancel some of the logger.info(), since in production we will not need them. Moreover, we need to log on a file with:

logging.basicConfig(filename='tweet.bot.log', level=logging.INFO)

That should be enough for the following.

Deploy it

When we are satisfied that everything works correctly, we can deploy it to DO App Platform

First let's commit

git add -A
git commit -m 'First Commit'

In order to deploy, we need to go to the main page of our app and select the Components tab:

We need to Create a New Component, and we select Worker

You need again to select the repository (if it does not show, just refresh the permissions, clicking on the link below the repository selection dropdown: change it, change it back and save)

Then you'll pick again the branch and the region of deploy.

After this, it will have detected a python service, but will be unable to detect the running command: just edit the run command as before:

python3 tweet.bot.py

Moreover, we will need to insert the ENVIRONMENT variables!

As there is not a way to load a file, we have to add them manually

Make sure to select [x] Encrypt where appropriate, so that it will add a security layer.

It is time to select a plan, and again we can select the smallest size.

Then we have to wait for the deploy

Now, we can try it online and see everything running smooth

We can also check the log file in the console

Conclusions

We have set up a worker to run as a bot

The only problem we have with this configuration is that it will occupy two DigitalOcean Containers: one for the service, and one for the worker.

However, this configuration is quite flexible.

Stay tuned for the following episodes.

Dev DigitalOcean Hackathon: Geobot, a Geography Python Twitter Bot - Tut 01

Davide Del Papa — Sat, 02 Jan 2021 15:07:26 +0000

[Photo by vivek kumar on Unsplash, modified(cropped)]

I started surveying the Dev DigitalOcean Hackathon with an article on deploying a Rust application.

However, since Rust is a much technical language, and it is not so far supported by DigitalOcean App Platform, I decided to go the Python way for this hackathon.

Grab your laptop and a beer (or some spiked eggnog: it's still Christmas season after all!).

NOTE: read the official hackathon page. If you are following this tutorial to prepare for your own hackathon, there is a link to a form to fill in order to get 50$ for 60 days, good to test the environment and to participate to the hackathon without weighing too much on the wallet. Merry Christmas and a happy new year to us!

First Build

I will give for granted that you are using a POSIX like shell (mostly Bash, but I use ZSH).
So the following is just routine:

mkdir geobot
cd geobot

In the above you can change geobot to give your project a different name.

Now we can create a virtual environment for our app:

python3 -m venv venv

Since we need to push our app to GitHub in order to trigger the DigitalOcean builds, we need a .gitignore.

We could create our own, but I advise to use a ready-made one, from the official GitHub repo:

curl -L -o .gitignore https://raw.githubusercontent.com/github/gitignore/master/Python.gitignore

Now we can make our project's folder into a git repository:

git init

Time to activate our virtual environment:

source venv/bin/activate

(Remember: when you have finished, in order to deactivate the environment, just give the command deactivate straight to the shell).

Now we need to install our first dependencies.

We will use Flask as API Server Framework, and Gunicorn as WSGI HTTP server (think of it as an Apache for the Python frameworks).

pip install Flask gunicorn

We can also create a requirements.txt now, and in case of need, update it later on:

pip freeze > requirements.txt

Now let's create a minimalist Flask app, called app.py:

from flask import Flask
app = Flask(__name__)

@app.route('/')
def hello_world():
    return 'Hello world!'

We need to create a configuration file for Gunicorn, called gunicorn_config.py:

bind = "0.0.0.0:8080"
workers = 2

That will bind your server to the port 8080 of the localhost, from which DigitalOcean Apps will fetch it.

First Deploy

Now it's time to push to GitHub and deploy on DO App Platform.

Let's prepare our local repo:

git add -A
git commit -m 'First Commit'

Now you can create a new empty repo on GitHub, that we can enable as remote on the local one, and push our first commit to:

git remote add origin https://github.com/<yourname>/geobot.git
git push origin master

NOTE: very soon GitHub will change the defaults, and replace master with main. There will be a transparent method provided by GitHub to do so, therefore we will patiently wait the tools are in place (the official guides say to wait still). Otherwise branch now to main (git branch -M main) and push to main instead than to master.

Time for the DigitalOcean part.

Let's point our browser to the DO App Platform Homepage.

Click Launch Your App: if it's the first time it will ask you to connect your GitHub account. Just follow the procedure.

At the end you will be prompted to choose a repository

Click on Next and in page 2 you will be prompted to pick a name and a region of deploy

Click on Next and in page 3 it should have detected everything for you (that is, Python and even Gunicorn!). In case it has not, please refer to the following image for the right settings:

Everything is OK, but the Run Command: click Edit in there and add app:app at the end.

It should be:

gunicorn --worker-tmp-dir /dev/shm app:app

Now you can save and resume the wizard.

Upon clicking Next we will be given the opportunity to choose our Monthly plan and the size of our virtual server (available maximum resources).

Notice that the free plan is not available for web services, but only to host static resources.

Notice too in the bottom left of the above picture: DO defaults to the small S (10$ per month) server; however, there is an option for an XS (extra small) server (5$/Mo.); you can opt for that, at least when you are not deploying a business app, but just testing the environment.

Upon clicking on Launch Basic App you will be redirected to the page of your app, and you should see it loading the deploy

If you click on view Logs (on the top right), you can take a look to see if the deploy got stuck somewhere.

Once everything is done, you should see a Deployed successfully! message, and a link to the app under the app name:

If you follow the link, you should see our Flask app greeting us from the browser window:

Always an emotion!

Playing with your First App

You can go ahead and change the greeting message in app.py, for example:

@app.route('/')
def hello_world():
    return 'Hello from DO App Platform!'

Then, if you commit to GitHub

git add -A
git commit -m 'Showing Personalized Greeting Message'
git push origin master

you will see App Platform "instantly" rebuild the app for us:

At the end you will see the updated message:

Notice that while it is still building, DigitalOcean will keep the old version running, and when the deploy is completed it will substitute the new version for the old.

Quite neat!

Conclusion

For today it's all folks!
If you are completely new to this world, I hope you could follow the tutorial without problems.

Do not hesitate to write in the comments section.

As usual: stay excited, because something good's coming at the horizon!
Till next time!

Rocket Tutorial 05: Enforcing uniqueness of emails.

Davide Del Papa — Mon, 21 Dec 2020 18:18:01 +0000

[Photo by Terence Burke on Unsplash, modified (cropped)]

In the alternative tutorial 04 we discovered that our tests were not enough, and we left with the promise to take care of that. Here we are, honoring that promise.

Of course, we will not talk about just testing and testing forever... In fact we'll be strengthening security on our system by enforcing uniqueness of emails.

The code for this tutorial can be found in this repository: github.com/davidedelpapa/rocket-tut, and has been tagged for your convenience:

git clone https://github.com/davidedelpapa/rocket-tut.git
cd rocket-tut
git checkout tags/tut5

A promise is a promise: more on tests

Hold your horses, cowboy! First we need to honor the promise we made last time.

I'm still in the "Redis branch" of the repo: we'll change things here, test properly, and then I'll show a nice git trick, if you don't already know it, to merge back just the tests to master (where there's the MongoDB version).

We have to do two things: delete each user we insert in testing, and make sure that each email is unique.

As for the first thing we have to make sure that EACH user we insert is unique (i.e., no copy-pasta, even though I'm Italian and I love pasta)

The following is useful in almost any case we insert a user first:

if response.status() == Status::Ok {
    let res = client.delete(format!("/api/users/{}", id))
        .header(ContentType::JSON)
        .body(r##"{
            "password": "123456"
        }"##)
        .dispatch();
    assert_eq!(res.status(), Status::Ok);
}

Of course we have to fill in the right password.

In tests/basic_test.rs, in new_user_rt_test() we do not extract the user id at all, so we have to pass it on the fly, like so:

client.delete(format!("/api/users/{}", id))

In tests/failures_test.rs instead, in id_user_rt_fail() we have to extract the info of the id from the user.

However, remember that in tests/failures_test.rs we make the responses fail on purpose (it's our fails test); however we check always that the insertion was correct.
So, there's no need to check again if the insertion was correct, and we can take away the if altogether.

Instead in info_user_rt_fail(), before we forge a fake id, we need to clone() it:

let mut id = user_new.id.clone();

so that later on we can reuse user_new.id:

if response.status() == Status::Ok {
    let res = client.delete(format!("/api/users/{}", user_new.id))
        .header(ContentType::JSON)
        .body(r##"{
            "password": "123456"
        }"##)
        .dispatch();
    assert_eq!(res.status(), Status::Ok);
}

In tests/persistency_test.rs too we do not extract the id info from the response; we have also to remember that we cannot access anymore the first client,so we have to just call client2:

let res = client2.delete(format!("/api/users/{}", user.id))

And that is it: if we adapt a little the code and the passwords.

Now we can test everything and cleanup after our mess. Well done.

Even checking in the Redis part all the keys present in the DB 1 we get:

127.0.0.1:6379[1]> keys *
(empty list or set)

In fact, the lookup key gets also destroyed once its values are depleted.

Now that everything is fixed we'd like to commit those changes to the Redis branch, but also bring them to the MongoDB branch (assuming it's master; if it's main correct the following as needed). No worries we can do that easily

First commit all changes to the Redis branch; then we move back to master

~$ git checkout master
Switched to branch 'master'
~$  git checkout tut04alt tests/basic_test.rs tests/failures_test.rs tests/persistency_test.rs
Updated 3 paths from 69b3ab7

That is, on master we give the git branch <name_of_branch_to_copy_from> <path/to/file> <path/to/file> ... and git will stage for us in master the modifications to the files from the other branch we want copy also on the current branch.

Let's check now:

~$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    modified:   tests/basic_test.rs
    modified:   tests/failures_test.rs
    modified:   tests/persistency_test.rs

Sorry for this interlude about git-foo, but it is convenient to know while working on many branches at the same time. Now we can commit on master as well.

Second promise: Unique emails

Now we need a new test to check whether our system accepts only one unique email or not.

It's a case fit for failure so, we modify our tests/failures_test.rs

#[test]
fn unique_emails_insertion_fail(){
    let client = common::setup();

    // First user with its email
    let mut response_new_user = client.post("/api/users")
        .header(ContentType::JSON)
        .body(r##"{
            "name": "Jared Doe",
            "email": "jthebest@m.com",
            "password": "123456"
        }"##)
        .dispatch();
    // We have to make sure this does not fail because of wrong new user insertion
    assert_eq!(response_new_user.status(), Status::Ok);
    assert_eq!(response_new_user.content_type(), Some(ContentType::JSON));
    let response_body = response_new_user.body_string().expect("Response Body");
    let user: ResponseUser = serde_json::from_str(&response_body.as_str()).expect("Valid User Response");

    // Second user with the same email
    let mut response_second_user = client.post("/api/users")
        .header(ContentType::JSON)
        .body(r##"{
            "name": "Joy Doe",
            "email": "jthebest@m.com",
            "password": "qwertyuiop"
        }"##)
        .dispatch();

    assert_ne!(response_second_user.status(), Status::Ok);
    assert_eq!(response_second_user.content_type(), Some(ContentType::JSON));
    assert_eq!(response_second_user.body_string(), Some("\"email already in use\"".to_string()));

    // Cleanup
    let res = client.delete(format!("/api/users/{}", user.id))
        .header(ContentType::JSON)
        .body(r##"{
            "password": "123456"
        }"##)
        .dispatch();
    assert_eq!(res.status(), Status::Ok);
}

In the above we insert a user and then attempt to insert another one with the same email as the first.

In the code we've added also another test, unique_emails_update_fail(), for the PUT route, to update the user. This test inserts two different users and is set to fail when updating the first user we use the same email as the second user.

If we run cargo test of course it will fail.

test unique_emails_insertion_fail ... FAILED
test unique_emails_update_fail ... FAILED

Moreover, now we will have to clean the DB by hand as well.

Just for your info, I'm not fan of any software specifically, but if you do not really know how to use MongoDB and want a GUI to manage it, I'm using Robo 3t by robomongo. I'm not affiliated to nobody, just saying that which I happen to use, but there are other software out there, as well, just search for them.

Back to business, we have some emails to render unique.

Unique fields in MongoDB

We need to enforce an index out of a field, so that MongoDB will index by id, as well as by that index (in this case email).

There's not as yet this function on the mongodb crate. Besides, which part of the code should create it?

The only thing to do is to run the command on a MongoDB shell.

db.getCollection('users').createIndex( { "email": 1 }, { unique: true } )

I run it on Robo3t for example.

OK, there's technically another way to do it, in a more elegant way, and in a way that it is all done in Rust (think of deploying this quickly by an inexperienced user, without having to setup just about everything). We could create a lookup collection, in the same way we did with Redis, and use the email as ID, while setting as only field the User ID.

The data structure will look like this:

#[derive(Serialize, Deserialize, Debug, Clone)]
pub struct EmailLookup {
    #[serde(rename = "_id")]
    pub email: String,
    pub user_id: Uuid,
}

Serde will rename emailk to _id, and MongoDB will use this field as its id, instead of creating an id automatically. I mean, its the same technique we used for User.

You just put it in src/data/db.rs and you are set to go.

The procedure for insertion will be thus:

Check the lookup table: if the field already exists, let the insertion fail.
Insert the new user regularly, and extrapolate the ID
Insert the user by email in the lookup collection.

At this point we could change the retrieval of the get by email, but I do not advise doing so, because it would mean to first extract the ID, then use it to get the user by ID... oh my.

BIG WARNING: in MongoDB the _id (whatever its content) is immutable: when the user updates the email, you have first to delete the field, then create another one. Not that difficult, but keep an eye on it.

Anyway let's discard the idea of a separate lookup collection in this project (it's always up to you to implement it, if you want, I think we covered enough together for you at least to try).

We go for the quick-fix command described above. This leave us with the only task of getting the right error when inserting a new user.

In MongoDB's docs it is written that a non unique index key would result in an error of kind writeError with code 11000. We have to get this same Error definition in mongodb crate.

It is in mongodb::coll::error::WriteError:

pub struct WriteError {
    pub code: i32,
    pub message: String,
}

Now we know we have to match that same error code. Let's find in src/routes/user.rs when we insert a new user:

match user_coll.insert_one(document.to_owned(), None) {
    Ok(inserted) => {
        match inserted.inserted_id {
            Some(id) => { ...},
            None => ApiResponse::internal_err(), // here!
        }
    },
    Err(_) => ApiResponse::internal_err(), // not here!
}

Why there and not on the error? Because the error is when there's not an answer from the MongoDB server, but an answer WITH an error is covered somewhere else. Actually, the response is a

pub struct InsertOneResult {
    pub acknowledged: bool,
    pub inserted_id: Option<Bson>,
    pub write_exception: Option<WriteException>,
}

You can see that there's the option with the id inserted, but if that is None then the write_exception contains the error. PS: acknowledged contains how many records have been written, so in this case that is 0 since it is an insert_one; if it were a bulk insertion it could have had info of fields written and fields with exceptions...

Let's get back on track:

We have to change the None where it says // here! to:

None => match inserted.write_exception {
    Some(wite_error) =>{
        match wite_error.write_error {
            Some(err) =>{
                match err.code {
                    11000i32 => ApiResponse::err(json!("email already in use")),
                    _ => ApiResponse::internal_err(),
                }
            },
            None => ApiResponse::internal_err(),
        }
    },
    None => ApiResponse::internal_err(),
}

As for the other route we have to check, update_user_rt(), we just need to briefly check that the email does not yet exist, right after we authenticate the password.

[...]
if found_user.match_password(&user.password) { // After this
    let insertable = found_user.update_user(&user.name, &user.email);
[...]

We'll borrow the find_one() scheme from id_user_rt() (that finds users through the email): if we find one we'll sen the error about the email already in use, otherwise we'll let everything work normally.

if found_user.match_password(&user.password) {
    // Check the email does not yet exist
    match user_coll.find_one(Some(doc! { "email": &user.email }), None) {
        Ok(mail_query_result) => {
            match mail_query_result {
                Some(_) => { return ApiResponse::err(json!("email already in use")); },
                None => ()
            }
        },
        Err(_) => { return ApiResponse::internal_err(); }
    }
    let insertable = found_user.update_user(&user.name, &user.email);

Now we have implemented in both routes the "email already in use" error. We should build and test (fingers crossed).

test unique_emails_insertion_fail ... ok
test unique_emails_update_fail ... ok

I can consider that a personal win.

Uniqueness in Redis

Let's commit, switch over to Redis and bring the new test in there... And let's hope the fix will be quick.

git push origin master
git checkout tut04alt
git checkout master tests/failures_test.rs

As for Redis the only way of enforcing uniqueness is through a set, that is a container of unique objects.

Example:

$ redis-cli
127.0.0.1:6379> sadd mykey "one"
(integer) 1
127.0.0.1:6379> sadd mykey "two"
(integer) 1
127.0.0.1:6379> sadd mykey "one"
(integer) 0
127.0.0.1:6379> smembers mykey
1) "two"
2) "one"
127.0.0.1:6379>

The integer answer is the number of members added (can be more than one at a time). When re-adding the same member we see that it returns 0, and checking the list of members we see that there are no duplicates.

Let's implement it in code. Briefly we have to:

Add a email to a set each time it is serialized a user. We do not need per se to check for failures there, in fact, we should check for failures beforehand. But anyhow, it is better to check.
Before each insert, we need to make sure that the email does not already exist.
Before updating with a new email we need to check that it is not already in use.
We have to cleanup the email before updating it, and also change password (because the user gets re-inserted). Also we have to cleanup he email once we remove the user.

As to the point 1, we change the to_redis() method to look like:

fn to_redis(self, connection: &mut Conn) -> AnyResult<()> {
    let id = self.id.to_string();
    let email = self.email.clone();
    let r_user = [
        ("name", self.name),
        ("email", self.email.to_lowercase()),
        ("hashed_password", self.hashed_password),
        ("salt", self.salt),
        ("created", self.created.to_string()),
        ("updated", self.updated.to_string())
    ];
    connection.hset_multiple(&id, &r_user)?;
    // Enforce email uniqueness
    let res_enforce: i32 = connection.sadd(UNIQUE_EMAIL_SET, email.clone())?;
    // Add email lookup index
    if res_enforce != 0 {
        let _ = connection.zadd(LOOKUP, format!("{}:{}", email, id), 0)?;
    } else {
        bail!("email already in use");
    }

    Ok(())
}

We have to render all email lowercase, because sadd is case sensitive.

We create a new User method to check uniqueness as well:

fn is_unique_email(self, connection: &mut Conn) -> AnyResult<bool> {
    let res_enforce: Result<i8, _> = connection.sismember(UNIQUE_EMAIL_SET, self.email);
    match res_enforce {
        Ok(res) => {
            if res == 0 { return Ok(true); }
            return Ok(false);
        },
        Err(_) => Err(anyhow!("Connection error")),
    }
}

I'm not going to discuss all the other routes, I think it is easy to check them, but this is the POST route:

#[post("/users", format = "json", data = "<user>")]
pub fn new_user_rt(mut connection: Conn, user: Json<InsertableUser>) -> ApiResponse {
    let ins_user = User::from_insertable((*user).clone());
    match ins_user.clone().is_unique_email(&mut connection) {
        Ok(res) => {
            match res {
                true => {
                    match ins_user.clone().to_redis(&mut connection){
                        Ok(_) => ApiResponse::ok(json!(ResponseUser::from_user(&ins_user))),
                        Err(_) => ApiResponse::internal_err(),
                    }
                },
                false => ApiResponse::err(json!("email already in use")),
            }
        },
        Err(_) => ApiResponse::internal_err(),
    }
}

Easy, isn't it?
A quick build&run confirms that everything is as it is supposed to be.

Conclusions

I think we can call it a day, although we didn't lean anything new about Rocket or about integrating it with other software, as we did in the last tutorials.

Besides, learning how to strengthen security on our systems by enforcing uniqueness of a field is a skill useful not just to this specific case: there are many cases in which fields have to be unique and index-like, independently of the real index.

Next time I will introduce a new concept to work with Rocket, and we will use it to authenticate our Users to the platform (finally).
So, stay tuned!