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

Every module should 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
    - 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 (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

SQLite used to operate with user profile: for example, restore and save widget sessions, manage auth, history, bookmarks, etc
Database stored in system config directory (could be detected simply using browser tools menu)
Every browser mod may have own table, where table must:
- contain same name as mod location, for example app_browser_widget for src/app/browser/widget.rs
- every table include autoincrement id column and parental primary ID if exist
  - column name for parental ID must have absolute namespace prefix, for example app_browser_id column for app_browser_widget table. For example, if the table has few parental keys, column set could be id, parent_one_id, parent_two_id, some_data
todo
- version control for auto-migrations
- transactions support for update operations

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
Started refactory on separate widgets implementation to separated mods, because widgets may contain own tables in database and require additional mods dependencies like ORM API todo

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