# 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

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
```