commit 9adf1410a31d1b4411aaf375ec50ab8af6148fb6 Author: Pascal de Vink Date: Sat Jun 28 14:55:32 2025 +0200 Initial commit containing the first set up of a new rust application, vision doc, first ADRs, and first tasks diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..b83d222 --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +/target/ diff --git a/Cargo.toml b/Cargo.toml new file mode 100644 index 0000000..4d9dacd --- /dev/null +++ b/Cargo.toml @@ -0,0 +1,6 @@ +[package] +name = "audio_always_works" +version = "0.1.0" +edition = "2024" + +[dependencies] diff --git a/docs/adr/001-rust_core_native_shell.md b/docs/adr/001-rust_core_native_shell.md new file mode 100644 index 0000000..2a31589 --- /dev/null +++ b/docs/adr/001-rust_core_native_shell.md @@ -0,0 +1,21 @@ +# Rust core, native shell + +## Context and Problem Statement +The idea of this application is that it works on different platforms, via GUI and CLI, whilst still maintaining a native feel, and low resource usage. + +## Considered Options +- React native +- Electron/nodejs +- Tauri +- Rust core, native shell + +## Decision Outcome +Because this application needs access to low-level system APIs on different platforms, that might not be available via NodeJS/javascript, React native and Electron were not valid options. + +Quickly, Tauri came into view, because its Rust core allows for access to these low-level system APIs. However, its browser-based GUI rendering does not feel completely native, at least not without considerable effort. + +Finally, the author's aim is to also learn more about Rust and its ecosystem, so using Rust at the core, whilst integrating a native GUI shell seems like a good course at this time. + +### Consequences +There might be less boilerplate available for creating a cross-platform, native look-and-feel application, which might slow down development. +However, it does allow the scope to be limited to macOS and GUI first, before focussing on cross-compliation and extending further. diff --git a/docs/adr/002-crux.md b/docs/adr/002-crux.md new file mode 100644 index 0000000..4658d4a --- /dev/null +++ b/docs/adr/002-crux.md @@ -0,0 +1,19 @@ +# Crux as a framework for rust core, native shell + +## Context and Problem Statement +Upon diving deeper into the options to implement the core in rust, but the outer shell in native code, it became apparent that this is still a relatively new field. Often times, these implementations rely on non-native solutions in the outer shell, like tauri, and flutter. These are best developed, but were discarded in 001. + +## Considered Options +- Writing from scratch +- Crux + +## Decision Outcome +Although Mitchell Hashimoto has recently shown with his implementation of Ghostty, that it is perfectly possible to hand-roll a native shell for a different core (zig in his case), using a framework that is used by multiple other projects and people gives me more confidence in the approach. Although Crux is not perfect, and doesn't fully support Windows and Linux (yet), as they focus more heavily on mobile, it is a good enough starting point to build upon and learn more about both rust, and the development of this application. +Crux heavily relies on ports-and-adapters architecture, as well as event sourcing, which is a good fit for the rust core, native shell approach. + +### Consequences +It will not be immediately possible to build a Windows and/or Linux outer shell. This is acceptable for now. + +Crux's reliance on event sourcing means it's possible to define which events and subsequent commands need to be supported, as shown here: + +![002-events.png](002-events.png) diff --git a/docs/adr/002-events.drawio b/docs/adr/002-events.drawio new file mode 100644 index 0000000..a2ab459 --- /dev/null +++ b/docs/adr/002-events.drawio @@ -0,0 +1,85 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/docs/adr/002-events.png b/docs/adr/002-events.png new file mode 100644 index 0000000..259f389 Binary files /dev/null and b/docs/adr/002-events.png differ diff --git a/docs/adr/003-nom_parser_generator.md b/docs/adr/003-nom_parser_generator.md new file mode 100644 index 0000000..8e9911b --- /dev/null +++ b/docs/adr/003-nom_parser_generator.md @@ -0,0 +1,10 @@ +# Nom as Parser Generator + +## Context and Problem Statement + + +## Considered Options + +## Decision Outcome + +### Consequences diff --git a/docs/tasks/0001-create_native_shell_app.md b/docs/tasks/0001-create_native_shell_app.md new file mode 100644 index 0000000..e69de29 diff --git a/docs/tasks/0002-list_input_and_output_audio_devices.md b/docs/tasks/0002-list_input_and_output_audio_devices.md new file mode 100644 index 0000000..e69de29 diff --git a/docs/tasks/0003-create_rules_dsl_interpreter.md b/docs/tasks/0003-create_rules_dsl_interpreter.md new file mode 100644 index 0000000..e69de29 diff --git a/docs/tasks/0004-display_rules_in_gui.md b/docs/tasks/0004-display_rules_in_gui.md new file mode 100644 index 0000000..e69de29 diff --git a/docs/tasks/0005-create_rules_via_gui.md b/docs/tasks/0005-create_rules_via_gui.md new file mode 100644 index 0000000..e69de29 diff --git a/docs/tasks/0006-store_rules_in_config_file.md b/docs/tasks/0006-store_rules_in_config_file.md new file mode 100644 index 0000000..e69de29 diff --git a/docs/tasks/0007-read_config_file_on_start.md b/docs/tasks/0007-read_config_file_on_start.md new file mode 100644 index 0000000..e69de29 diff --git a/docs/tasks/0008-hide_in_menu_bar.md b/docs/tasks/0008-hide_in_menu_bar.md new file mode 100644 index 0000000..e69de29 diff --git a/docs/tasks/0009-execute_rules_on_device_change.md b/docs/tasks/0009-execute_rules_on_device_change.md new file mode 100644 index 0000000..e69de29 diff --git a/docs/vision/vision.md b/docs/vision/vision.md new file mode 100644 index 0000000..0754ad9 --- /dev/null +++ b/docs/vision/vision.md @@ -0,0 +1,8 @@ +# Vision for the application + +With this application it's possible to define rules that allow the user to set the default input and output audio device based on the given predicates. +Predicates could be many different system states, but the first version will just focus on the available input and output audio devices. +The application should present itself as a GUI application, supported on macOS, Windows, and Linux flavours, as well as be available as a CLI application. This allows for the most flexible usage. +The first version of this application will focus on a macOS GUI though. +Rules configuration will be stored as a file in the user's home folder, which allows it to be edited by any text editor as well as the GUI. +The application should feel snappy and its GUI native. Because it is always running in the background, the resource usage should be very low. diff --git a/src/main.rs b/src/main.rs new file mode 100644 index 0000000..e7a11a9 --- /dev/null +++ b/src/main.rs @@ -0,0 +1,3 @@ +fn main() { + println!("Hello, world!"); +}