Yoda - Browser for Gemini protocol

GTK 4 / Libadwaita client written in Rust

[!IMPORTANT] Project in development!

Features

Interface

• Multi-tab
• Hotkeys
• Bookmarks
• Build-in multimedia support
  • Images
  • Audio
  • Video
• Certificates management
• Downloads
• History
• Proxy
• Session
  • Window
    • Size
    • Tabs
      • Pin
      • Page
        • Navigation
          • Request
          • History
• User settings

Protocols

Gemini

• Status codes
  • Success
    • 20
  • Input
    • 10 Input
    • 11 Sensitive input
  • Redirection
    • 30 Temporary (partial)
    • 31 Permanent (partial)
  • Temporary failure
  • Permanent failure
  • Client certificates
• Gemfeeds

Nex

Local

Media types

Text

• text/gemini
• text/plain

Images

• image/gif
• image/jpeg
• image/png
• image/webp

Audio

• audio/mpeg
• audio/ogg

Video

Build

Requirements

Make sure your system support:

• Glib 2.56+
• GTK 4.10+
• Libadwaita 1.6+

Use rustup installer to setup latest Rust compiler and Cargo package manager:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Debian

todo

Fedora

sudo dnf install git gcc\
                 cairo-devel glib2-devel gtk4-devel libadwaita-devel pango-devel\
                 sqlite-devel

Install

Stable

cargo install Yoda

Repository

git clone https://github.com/YGGverse/Yoda.git
cd Yoda
cargo build

Development

Quick start guide and maintenance protocol

browser

Filesystem

• 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

Codebase

• 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 names: from, new or/and new_arc, new_mutex, etc - on return object in container
      • 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

Database

• 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)
• Structure of table should not be modified on CARGO_PKG_VERSION_PATCH change
• 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

GTK

• 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

Contribution

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

Releases

• Package version in repository should be increased immediately after stable release on crates.io and before apply new changes
• Currently, profile data stored in separated sub-directories, auto-created on every CARGO_PKG_VERSION_MAJOR or/and CARGO_PKG_VERSION_MINOR change

See also

• ggemtext - Glib-oriented Gemtext API
• ggemini - Glib-oriented client for Gemini protocol (in development)