# 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:
```bash
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:
```bash
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
Linux (x11) and windows can open and close a native window.
## Plans
Still gotta get around to painting pixels and calling callbacks.
Use `#[no_mangle]` to provide C-compatible bindings. While written in rust, this library
should be usable by C, C++, and any other language (Python?) that wants easy window creation.
OSX support.
Web support.
This will be a flag on the binary that spawns an HTTP server and makes the window ::display() function block until a client connects,
then serves them an HTML/JS shell which will paint pixels to a `<canvas>` element and push events and updates over a websocket.
## 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
ls -lh target/package/rust-cgui-*.crate
cargo publish
```
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
```