mirror of https://github.com/YGGverse/Yoda.git
phpcomposergeminigemini-protocolsmallwebaltwebgtk3browsergtkphp-gtkgemini-clientyoda-browserphp-cppgemini-browseryoda
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
3.5 KiB
3.5 KiB
Yoda - Browser for Gemini protocol
Rust / GTK 4 implementation
[!IMPORTANT] Project in development!
Install
Stable
cargo install Yoda
Repository
git clone https://github.com/YGGverse/Yoda.git
cd Yoda
git checkout Rust-GTK4
cargo run
Development
Guide and protocol draft
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
- implementable
- contain main
struct
implementation:- at least one constructor that must:
- have common for application name:
new
- return unwrapped (except
Option
,Result
), activated newSelf
object - grant ownership for new
Self
object created
- have common for application name:
- public
activate
action if the new object can not be activated on construct - public
link
getter for GTKwidget
(parental composition)
- at least one constructor that must:
- 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)
- Every
browser
mod may have own table, where table must:- contain same name as mod location, for example
app_browser_widget
forsrc/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 forapp_browser_widget
table. For example, if the table has few parental keys, column set could beid
,parent_one_id
,parent_two_id
,some_data
- column name for parental ID must have absolute namespace prefix, for example
- contain same name as mod location, for example
- 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, make sure:
- new branch created for every new PR
git checkout -b 'contribution-name'
- new code follows common rustfmt style
cargo fmt --check
- new branch created for every new PR