mirror of https://github.com/YGGverse/Yoda.git synced 2026-03-31 16:45:27 +00:00

Browser for Gemini Protocol https://crates.io/crates/Yoda

Find a file

yggverse f105b0946b update readme		2024-10-04 03:33:23 +03:00
src	move error handle outside	2024-10-04 02:57:50 +03:00
.gitignore	initial commit	2024-09-18 15:54:15 +03:00
Cargo.toml	change sqlite wrapper to rusqlite, update database api	2024-10-02 20:00:08 +03:00
LICENSE	initial commit	2024-09-18 15:54:15 +03:00
README.md	update readme	2024-10-04 03:33:23 +03:00
rustfmt.toml	init rustfmt.toml	2024-09-20 19:09:23 +03:00

Yoda - Browser for Gemini protocol

Rust / GTK 4 implementation

Important

Project in development!

Install

cargo install Yoda

git clone https://github.com/YGGverse/Yoda.git
cd Yoda
git checkout Rust-GTK4
cargo run

Guide and protocol draft

Use modern path pattern
One module implements one GTK widget, it may include additional helper files in same location (like template, CSS or DB API)
For children widget - create children module, located according to hierarchy

The codebase must be as minimal as possible, separate:
- different tasks
- massive structures
- structures with implementation
Every module must:
- encapsulate it members: compose childs and stay composable for parents
- access 1 level of childs, never parents (e.g. through super)
- implement only one public API struct per file (same as one file for one class)
  - implementable struct is public, where it members - private
- contain main struct implementation:
  - at least one constructor that must:
    - have common for application name: new (for widget) or/and init (for database)
    - return unwrapped (except Option, Result), activated new Self object
    - grant ownership for new Self object created
  - public activate action if the new object can not be activated on construct
  - public link getter for GTK widget (required for parental composition)
Public API oriented to simple (integer, boolean), standard (std::*) or system-wide (gio, glib, etc) data types usage to reduce internal dependencies from app implementation

Operate with action objects instead of names like win.action. This allows to follow encapsulation, by the our goal, module must know nothing about parent presets. For example, define some action in parent, then delegate object created as construction argument

before commit, make sure:
- new branch created for every new PR git checkout -b 'contribution-name'
- new code follows common rustfmt style cargo fmt --check