Uses old Rust 2015
0.1.22 |
|
---|---|
0.1.21 |
|
0.1.11 |
|
0.1.2 |
|
#89 in #title
36 downloads per month
Used in rust-cgui-render
52KB
946 lines
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
Dependencies
~17MB
~166K SLoC