crossterm-rs

Building a Terminal-Based GitHub Control Panel in Rust: Meet git-pulse 🚀 !git-pulse --- 🛠 What is git-pulse? git-pulse is a fast TUI (Terminal User Interface) built using Ratatui and Crossterm. It serves as a unified terminal control panel for GitHub, allowing developers to discover trending repositories, monitor project stats, and navigate through repos without opening a browser tab. Key Features: - Terminal-Native GitHub Dashboard: View trending repositories across various programming languages. - Live In-Memory Filtering: Press / to instantly search and filter repos by name, topic, or language. - Custom Color Themes: Toggle between clean visual themes (including Dracula and custom HEX palettes) with T. - Instant Repo Actions: Copy clone commands directly (c) or launch repositories in your browser (o). - Keyboard-First Navigation: Smoothly switch tabs (Tab) and jump between lists (j/k). --- 🚀 Quick Installation You can easily install git-pulse via cargo: cargo install git-pulse Or clone the repository and build from source: git clone [https://github.com/weaztoven/git-pulse.git](https://github.com/weaztoven/git-pulse.git) cd git-pulse cargo build --release --- ⚡ How to Use It Once launched with git-pulse, you can control the entire dashboard using intuitive hotkeys: | Key | Action | | --- | --- | | Tab | Switch between Watchlist, Trending, and My Repos | | / | Start live filtering | | Esc | Clear filter / exit search mode | | T | Change color theme | | c | Copy clone URL to clipboard | | o | Open current repository in browser | | q | Quit application | --- 🤝 Open Source & Contributions git-pulse is fully open-source and built with the Rust community in mind. - GitHub Repository: github.com/weaztoven/git-pulse - Crates.io Package: crates.io If you find this project helpful or have ideas for new features (like pull request management or issue tracking), feel free to leave a star ⭐️ on GitHub, open an issue, or submit a PR! --- What tools do you use to manage your GitHub workflow from the terminal? Let me know in the comments below!

Termtastic — new TUI client for Linux, macOS and Windows preview.redd.it Hello, guys! I wanna introduce you Termtastic — my handmade feature-rich Meshtastic® console (TUI) client written in Rust. preview.redd.it Channels screen Chat Nodes tab Traceroute results Multiline message support Emojis Logs tab Settings tab Repo link: acelot/termtastic I wanted to create a cross-platform, minimalist, and aesthetically pleasing console client. I’ve been working on this application for six months. The entire project was built by hand, without the use of AI (aside from looking up reference information). This process gave me a deep understanding of how Meshtastic works under the hood; I’ve thoroughly explored its protocol and behavioral nuances. As the project evolved, I contributed to the official Meshtastic library for Rust, adding new features and making minor fixes. The long-term goal of the project is to achieve feature parity with the official Android app. The project is currently in the alpha-testing stage, so there may be bugs — some of which could even cause the program to crash. That’s why I need your help: please give my application a try — I’m confident many of you will enjoy it! Any feedback is welcome via Issues in Github. Highlights - Vibecode-free fully handwritten code - Dependency-free single-binary application - Cross-platform: Linux, macOS, Windows - Fully asynchronous (Tokio channels-based) - Optimized for small screens (down to 80x24 characters) - Respects the user terminal colors (no fancy opinionated TrueColor schemes) - Keyboard-centric UI navigation - Minimum use of emoji/non-ascii characters in UI - Small memory footprint (~20KB) - Supports multiple connection protocols (TCP, BLE, Serial) - Could discover devices automatically: BLE paired devices, TCP devices via mDNS, Serial devices - Uses standard system directories for storing configuration, database and logs Tech stack |Feature|Library| |:-|:-| |TUI: Framework|ratatui| |TUI: Backend|crossterm| |TUI: Inputs|ratatui-textarea| |TUI: Lists|tui-widget-list| |Interaction with Meshtastic|meshtastic| |Clipboard functionality|arboard| |Bluetooth devices discovery|btleplug| |TCP devices discovery|mdns-sd| |Logging|tracing| |Async/Channels|tokio| |Configuration|confy, etcetera| |Errors|anyhow, thiserror| |Datetime|chrono| |Emoji selector|emojis| |Local DB|rusqlite, rusqlite_migration| Download Latest releases are available here: github.com/acelot/termtastic/releases

Lemme introduce to you my TUI client — Termtastic Hello, guys! I wanna introduce you Termtastic — my handmade feature-rich Meshtastic® console (TUI) client written in Rust. preview.redd.it Repo link: acelot/termtastic I wanted to create a cross-platform, minimalist, and aesthetically pleasing console client. I’ve been working on this application for six months. The entire project was built by hand, without the use of AI (aside from looking up reference information). This process gave me a deep understanding of how Meshtastic works under the hood; I’ve thoroughly explored its protocol and behavioral nuances. As the project evolved, I contributed to the official Meshtastic library for Rust, adding new features and making minor fixes. The long-term goal of the project is to achieve feature parity with the official Android app. The project is currently in the alpha-testing stage, so there may be bugs — some of which could even cause the program to crash. That’s why I need your help: please give my application a try — I’m confident many of you will enjoy it! Any feedback is welcome via Issues in Github. Highlights - Vibecode-free fully handwritten code - Dependency-free single-binary application - Cross-platform: Linux, macOS, Windows - Fully asynchronous (Tokio channels-based) - Optimized for small screens (down to 80x24 characters) - Respects the user terminal colors (no fancy opinionated TrueColor schemes) - Keyboard-centric UI navigation - Minimum use of emoji/non-ascii characters in UI - Small memory footprint (~20KB) - Supports multiple connection protocols (TCP, BLE, Serial) - Could discover devices automatically: BLE paired devices, TCP devices via mDNS, Serial devices - Uses standard system directories for storing configuration, database and logs Tech stack |Feature|Library| |:-|:-| |TUI: Framework|ratatui| |TUI: Backend|crossterm| |TUI: Inputs|ratatui-textarea| |TUI: Lists|tui-widget-list| |Interaction with Meshtastic|meshtastic| |Clipboard functionality|arboard| |Bluetooth devices discovery|btleplug| |TCP devices discovery|mdns-sd| |Logging|tracing| |Async/Channels|tokio| |Configuration|confy, etcetera| |Errors|anyhow, thiserror| |Datetime|chrono| |Emoji selector|emojis| |Local DB|rusqlite, rusqlite_migration| Download Latest releases are available here: github.com/acelot/termtastic/releases

Library design Hey! I'm working on a terminal manipulation library in Zig called termy, inspired by Rust's Crossterm. It's still early in development, and I'm trying to figure out the API before I get too far into the project. One thing I'm unsure about is whether terminal operations should work directly, like this: try termy.setForeground(&writer, .red); try termy.writeAll(&writer, "Some Error!\n"); try termy.setForeground(&writer, .reset); Or whether I should use a queue-based approach, similar to crossterm where you queue multiple commands and write them together: try termy.queue(&writer, .{ termy.style.Fg.Color{ .Red = {} }, termy.style.Print{ .msg = "Some Error!\n" }, termy.style.Fg.Color{ .Reset = {} }, }); try writer.flush(); I'm not sure which approach makes more sense in terms of performance and usability, or which feels more natural to use in Zig. I love how the data-oriented approach looks, but I think it may affect performance. I'd appreciate some feedback! - Which approach would you prefer, and why? - Would it make sense to support both? - Are there any common mistakes I should avoid when designing a Zig library? - What features would make you choose termy over other terminal libraries? I'm still working on the fundamentals, so I'd rather get the design right now than have to change everything later.

Windows Api or VT? Hello! I'm currently working on a terminal manipulation library similar to Crossterm, but I noticed that it uses runtime conditionals to decide whether to use VT sequences or Windows API calls. Personally, I feel that defaulting to Windows API calls on Windows would be the better approach, or provide a build flag that lets users decide. However, I'm not sure which of these three approaches is best. Which approach do you think is better, and why?

Bliss Writer -- TUI Screenwriting software built with Roc May not be useful to people here, but the tech is cool. Gets around 500-700 fps for all usage except typing, which is just in the 200s at the moment. Built with Roc lang + Crossterm roc-lang.org crossterm-rs/crossterm Packaged with Trolley: weedonandscott/trolley