Crates.io | udokai |
lib.rs | udokai |
version | 0.0.1 |
source | src |
created_at | 2024-11-24 09:34:28.531341 |
updated_at | 2024-11-24 09:34:28.531341 |
description | The launcher for unix-like systems - udokai |
homepage | |
repository | |
max_upload_size | |
id | 1459071 |
size | 48,565 |
THIS IS VERY MUCH A WORK IN PROGRESS.
At work I use MacOS and at home Linux (NixOs). I have to keep 2 configurations of the same kinda of tools (Alfred and Ulauncher). I wanted to have an unique configuration and the same UX for both systems.
Not to mention that versioning configuration for these tools is a pain, they weren't designed to be versioned.
Udokai idea is to be simple but extensible launcher, that uses a standard configuration language, like Toml/Yaml, which can be easily versioned and used in any unix-like system. Its Architecture is heavily inspired by pop-launcher
Hopefully, this project will be a solution for me and for others that have the same need :)
The client and the server(s) process(es) will always be running in the background, to ensure its snapyness to respond to the user's input. The client will mutiplex the keypress events to the servers. The servers will process the keypress events and return a list of items to the client. The client will aggregate the responses and display them to the user. The user will select an item and the client will send the command to the server to execute the action.
sequenceDiagram
autonumber
participant GUI/TUI
participant Client
participant Server1
participant Server2
participant OperationSystem
GUI/TUI->>Client: Keypress Event
Client->>Server1: Forward Keypress Event
Client->>Server2: Forward Keypress Event
Server1-->>Client: Processed Response (e.g., "Action1")
Server2-->>Client: Processed Response (e.g., "Action2")
Client-->>GUI/TUI: Aggregated Responses ("Action1", "Action2")
GUI/TUI->>Client: Select an action (Action1)
Client->>Server1: Send selected action (Action1)
Server1->>OperationSystem: Execute Action1
On the context of the launcher a plugin will run a server that will be connected to the client. Allowing developers to create their own plugins to extend the launcher.
- How to make the plugins discoverable? or should they be configurable?
- How to translate the commands to the OS? (e.g., open an application, open a file, etc)
* Maybe each plugin server will be responsible to translate, or work on a specific OS only
- How to handle the aggregation of the responses from the servers?
There are 3 main process in this project: UI(main), Client, and Server. The UI is responsible for rendering the user interface, the client is responsible for forwarding the user's input to the server processes, and the server processes are responsible for processing the user's input and returning a list of items.
They log to log files in /tmp/{name}.log directory. When working on the project, you can run the following commands to see the logs:
Recommend running tail
in a separate terminal window to see the logs in real-time.
# First terminal
tail -f /tmp/ui.log
# Second terminal
tail -f /tmp/client.log
# Third terminal
tail -f /tmp/server1.log
Then in another terminal, you can run the following commands to start the processes:
make run