CGui

"Common GUI"

What?

A GUI experiment/library that builds standalone native executables without significant toolchain efforts.

Currently from a linux machine you can build a standalone linux64 binary with:

cargo build --release

To build win64, first install the cross cargo utility with cargo install cross.

Cross requires Docker to run.

Then add ~/.cargo/bin to your $PATH and build a win64 binary:

cross build --release --target x86_64-pc-windows-gnu

Built demo applications and a copy of the library may be found at https://git-community.cs.odu.edu/jmcateer/rust-cgui/wikis/Built-Releases

This is currently an experiment, but will gradually move towards a reusable library with a sane interface.

I expect the library will stop at the "window" level of encapsulation. No support for cross-platform Modal Dialogues is planned. Instead you will create CWin structs ("objects"), which will have very minimal metadata and events:

CWin {
  title: String,           // Not guaranteed to be rendered, as in tiling WMs
  desired_width_px: u16,   // Also not guaranteed
  desired_height_px: u16,  // Guess what? Not guaranteed
  pixels: Vec<Vec<u32>>,   // Your code will push changes here through some setters I need to think up.
                           // It is very important to the simplicity of the library
                           // that we only go from cli -> pixel buffer.
                           // anything further would force obnoxious paradigms on end developers.
                           // KISS.
  event_callbacks: Vec<fn(*mut CWin)>,
                           // Thought needs to go here as well, but I expect you will get
                           // a reference to the window, an enum with the event type ("MOUSE_MOVE", "KEY_PRESS"),
                           // and a generic argument which will need to be match{}-ed out. (mouse delta coords, key characters/codes)
}

There is also the inkling of a plan to add some sort of menu-bar structure, for systems like OSX which render that as something outside the window canvas.

I also do not plan to differentiate between a "pixel" and a "point". They're pixels, I will deal with the smallest possible integer pixel the screen will give me. Scaling content "nicely" is outsite the scope of this project.

Why?

GUI Libraries suck. They have considerable overhead, require significant tooling to cross-compile, and force developers to use a paradigm which may not suit their use case.

This library will be a "half-gui" toolkit. It aims to give a cross-platform ability to open a window, paint pixels, and execute simple event callbacks.

Widgets, scaling, any "model view controller" nonsense is completely outside the scope of this project.

There is of course no reason not to implement widgets on top of this, but I plan to keep the entire effort simple and composable.

Status

Download and use the library at https://git-community.cs.odu.edu/jmcateer/rust-cgui/wikis/Built-Releases

Plans

OSX support.

Anti-plans

Support for Wayland. It's tempting, but I haven't seen anything I'd call a "stable" implementation.

Mobile devices (anything you can't get a native terminal on).

99% of the "Web support" questions I expect to get. No we will not handle cookies, or headers, or compression, or authentication...

It's a buffer of pixels.

Things I will forget

Publish to crates.io:

cargo package && cargo publish
ls -lh target/package/rust-cgui-*.crate

Testing one-liner:

alias go='set-cpu game && cross build --release --target x86_64-pc-windows-gnu && ssh blog rm /ftp/public/cgui-bin.exe ; scp ./target/x86_64-pc-windows-gnu/release/cgui-bin.exe blog:/ftp/public'
go