Cogsy - a command line curses-based Discogs client written in Rust capabilities: saves a user's discogs collection into a local database pulls new collection updates from discogs random song functionality track listens and show listening history using unicode chars track money spent on record purchases and graph history using unicode chars (coming soon) aims to be as independent of the internet as possible - only connects to the internet to pull user data (i.e. when running update) - everything else is handled offline (locally) app flow: running without any arguments enters interactive mode else, when run with a command, executes command and exits commands can also be executed in interactive mode interactive mode layout: | |---main table of data (album title, artist, release year) | (user can change screen by pressing number keys and exit by pressing q) | |---command line (user can enter in commands with arguments and options) (accessed with vim-like keybindings ":") list of commands: - update (when run without options, pulls updates from discogs collection and wantlist and updates local database) -t, --token (updates the auth token stored locally) -u, --username (updates the username stored locally) username is stored with the database (when running update, it checks if the username has changed if changed, it purges the current database and repopulates it with entries from the new username's collection) - random (selects a random album from the database for user to play and adds entry to listening log) -n, --nolog (does not add to listening log) - price [album] [price] (sets the amount paid for the album) (not yet) - listen [album] (logs the album specified at the current time) - query [album] (queries the local database for album and displays release information) (no plans to support API queries) list of screens (accessed by typing their names in the commandline) 1: collection (main) - clicking enter on the entry brings up its release information 2: wantlist - same as collection 3: profile - displays user profile pulled from discogs plus some additional info - highest rated album - most listened album in the past 30 days - most listened album of all time - most expensive album - artist with the most albums in collection 4: history (graphs the listening history of an album) - side menu of each album in collection, search bar at top (up/down to scroll, the graph of the highlighted album on the right) 5: money spent (graph built with unicode braille) (not yet) 6: log (log of when albums were added) (not yet) dependencies -cursive 0.15.0 -> termion backend -reqwest 0.10.7 (api querying) -serde_json 1.0.115 (json deserialization) -rusqlite 0.23.1 (database interface) -clap 2.33.2 (command parsing) -regex 1.3.9 (regex matching) -chrono 0.4.15 (datetime support) -directories 3.0.1 (project directory) -unidecode 0.3.0 (ascii conversion) app structure: commands.rs utils.rs (various helper functions) main.rs (main event handling loop) commands.rs (command parsing) screens/ (screen layouts) |_collection.rs |_wantlist.rs |_profile.rs |_history.rs |_money.rs |_addlog.rs app/ (app logic) |_mod.rs (app and helper types) |_impl_app.rs (implementation block) |_database.rs (database handler functions) |_request.rs (api handler functions) |_update.rs (update functions) |_message.rs (message formatting) TODO: - [0.2.2] Progress bars with indicatif - [0.2.2] Changing username and token via command line - [0.2.2] Add date formatting as configurable - [0.2.2] Refactor DBError to an enum - [0.2.2] Reading from a csv input file - [0.3.0] Price command - Implement different colours for folder list (not important) - Refactor Release, implement display for user-facing types Future additions: - Option to read from csv instead of pulling from web (for larger collections and wantlists) Issues: - :update freezes the app while it runs - Storing DateTime as strings in the database doesn't sit well with me - Algorithm for generating sparkviews may not scale well Configuration: Theme Username Token Timezone Display Format Two options for loading in the popup screens: 1: Keep the screen data associated with the master app struct Somehow find a way to handle multiple mutable ownership, and have the closure edit the app struct fields 2: Dissociate the popup structs from the app Instantiate the structs within the closure i.e. Read from db, parse data, construct screen and display Only instantiated when closure fires and is never loaded beforehand