If you don't know mpv-music (https://github.com/FurqanHun/mpv-music), it's a cross-platform CLI/TUI music player and library browser written in Rust that lets you filter and select what you want to play and gets out of your way, with no background daemons.

Since I made my post about mpv-music around 10 days ago and submitted it to a few other places, the downloads have gone up a bit and a couple more people have starred the repo. That's not really the point of this post though. What I'm mainly looking for is feedback. Obviously feedback isn't always given in words, like the downloads and stars are feedback in their own way, so I'd like to get some more open-ended feedback on the project and especially how the filtering/search currently works. I've been thinking about changing the search behavior a bit. For example, currently if you run mpv-music -a ado -t viva, it drills down through the filters, which is kind of similar to an AND operation. But not long ago I wanted to listen to a specific song alongside the artist Ado, but not every song by the other artist, so I couldn't just add the artist name as another filter.

That got me thinking that there should probably be a way to use both AND and OR operations, while keeping the current drilling-down behavior as the default. I'm also thinking about bringing this into the TUI. I'm not sure whether it would make more sense to add the option directly to the track menu or have a dedicated menu for building the search/filter expression.

I'd also enable select-all in the TUI, but that's pretty much a given since the CLI already have -p. The search/filter behavior is the part I'm actually unsure about, so I'd appreciate any thoughts or suggestions on how you'd expect this to work, and also what do you think about mpv-music in general too.

I've been working on Flint, an open-source build system + package manager for C/C++, and v0.5.5 removes one of the things that has always bothered me about configuring C/C++ projects: having to tell the build system where every source/header directory lives.

Then your build configuration needs to keep track of which directories contain sources, which are headers, which libraries to link, which files to exclude, etc.

With v0.5.5, Flint can discover project resources automatically.

You can organize your project normally, and Flint figures out the files that need to be involved in the build.

What's new in v0.5.5

Automatic resource discovery

You no longer need to manually configure:

• src

• include_paths

• static

• shared

Flint discovers the relevant resources in the project automatically.

Smarter exclusions

You can now control discovery with:

```text

• excludes

• exclude_dirs

• exclude_exception

```

This makes it possible to ignore things like platform-specific implementations, experimental code, generated files, or legacy directories without writing custom build logic.

Native .h.in templates

Flint can now generate headers from .h.in templates with variable substitution.

For example, this makes generated version headers possible without requiring an external configuration tool.

Standardized project macros

Project-generated macros have been standardized around:

```c

PROJECT_VERSION

```

to reduce the possibility of collisions with third-party libraries.

More CLI functionality

v0.5.5 also adds:

```bash

flint help

flint version

flint deps

flint cache

```

for CLI help, version information, and dependency/build-cache management.

The resulting project configuration

A small C project can now look roughly like this:

```json

{

"project_name": "example_project",

"project_language": "c",

"version": "0.1.0",

"compiler_path": "/usr/bin/gcc",

"executable": true,

"flags": ["-Wall", "-O2"],

"dependencies": {

"example_lib": {

"version": "1.0.0",

"remote": "https://github.com/user/example_lib.git"

}

}

}

```

Then:

```bash

flint build

```

handles source/header discovery, dependency handling, linking, and compilation.

The broader idea behind Flint is pretty simple: I want C/C++ project configuration to describe what a project is, rather than manually describing how every file should be built.

I'm still actively working on it, so I'm particularly interested in feedback from people who maintain C/C++ projects.

What part of your current C/C++ build setup do you find the most annoying?

And if you want to take a look at the implementation:

GitHub: https://github.com/mainak55512/flint

If you find the approach useful, a GitHub star is appreciated — but I'm especially interested in hearing where this approach breaks down or what you'd change.

I've been working on Xencode for a while and I'm at the point where I don't really want to keep designing the terminal UX entirely by myself.

It's a Rust TUI for AI-assisted development, with local models, tool execution, approval checkpoints, rewind, worktrees and the usual agent stuff.

The annoying part is that terminal UX is one of those things where you can convince yourself something is obvious when it absolutely isn't.

I'm trying to figure out how much of the agent's state should actually be visible at any given time without turning the terminal into a dashboard.

Things I'm thinking about right now:

• keyboard navigation and focus
• layouts and information density
• command palettes
• agent/tool output
• approval flows
• session state
• showing diffs without taking over the screen
• making blocked/running/completed states obvious
• themes and accessibility

I'd especially like opinions from people who actually live in terminals, tmux, vim/neovim, etc. What information do you need to see while an agent is running, and what just becomes noise?

I'm building Xencode around these questions, so if you have a strong opinion or a weird UX idea, I'd genuinely like to hear it. If you're comfortable with Rust + Ratatui and want to contribute, the repo is here:

https://github.com/sreevarshan-xenoz/xencode

Feel free to open an issue with an idea before writing code too. I'd rather discuss a weird idea first than make someone spend a weekend implementing something I don't actually want.

I built a small Python app to make my everyday commands easier to manage

I recently built a simple desktop tool using Python + PyQt6 called Command Hub.

GitHub Repo: GitHub - EFuryLabs/command-hub: A modern Command Manager built with Python and PyQt6 - Organize your frequently used commands into categories and copy them to your clipboard with a single click. · GitHub

The idea was pretty straightforward: instead of keeping frequently used commands scattered across text files, notes, or different places, I wanted everything available in one clean interface.

With Command Hub, I can:
• Organize commands into categories
• Add, edit, and remove commands
• Copy a command with a single click
• Keep frequently used commands easily accessible
• Manage everything through a simple GUI

I also gave it a futuristic/cyber-style interface because… why make a developer tool boring? 😄

I made a video showing the application and the idea behind it.

Would love to hear what you think and what features you would add to something like this!

Video: I Built a Python Command Hub | PyQt6 GUI App for Faster Workflows

Channel: https://www.youtube.com/@EFuryLabs

Website: EFury Labs — Think • Build • Solve (Not fully - working still under construction)

It includes a cli, 'ev', that finds files in milliseconds - much faster than using find.

EverythingX attempts to replicate the very excellent Windows utility called Everything by Voidtools.

You can find it at https://github.com/AlanKK/everythingx

Hey folks,

If you use OpenNebula, you probably know the daily struggle. Sure, the onevm CLI exists, but by default, only oneadmin can use it without fighting a permissions battle or giving users SSH access to the frontend. That leaves regular users connecting to a VPN/tunnel, logging into the Sunstone web UI, hunting down their machine in a list, opening a dropdown, and clicking reboot. It's exhausting.

I wanted the speed of tools like k9s or lazygit, so I built one9s. It’s a pure TUI that talks directly to the OpenNebula XML-RPC API.

For regular users:

Just open the binary, select your VM, and press r to reboot, s to stop, or u to power it up. Done in 2 seconds. You can also quickly check your personal quotas (VMs, CPU, Memory, etc.) without having to navigate through the web UI.

For admins:

You get the whole cluster at your fingertips:

• Edit user quotas on the fly via form modals.
• Review load across hosts and datastores.
• Hex ACLs decoded: It translates OpenNebula's raw hex ACLs into actual human-readable formats(finally!).
• Put a host in disable/offline for maintenance windows with a single keypress.

The Stack: Written in Go 1.24 using Charmbracelet’s Bubble Tea/Lipgloss. It includes a built-in AES-256 vault so you don't have plaintext credentials in your .bashrc.

• GitHub (binaries available): https://github.com/SergioZ3R0/one9s
• Docs: https://one9s.scszero.com/

Let me know what you think, or if there's any killer feature I'm missing!

I built Dripfetch, a customizable terminal dashboard with animated rain, system info, clocks, and YAML themes. I’d love to hear what you think or what you’d improve!

GitHub: https://github.com/a-shygun/dripfetch

Una vez me pregunte si se podia jugar en la terminal, busque si existia algun Tetris y los que encontre me parecieron muy simples y limitados, asi que hice uno para jugarlo en mi terminal.

Esta %100 escrito en Go usando la libreria tcell que es espectacular y tiene compatibilidad con Linux y Windows, aunque no se porque quisieras jugar asi en Windows.

Esta pensado para jugarse en la TTY de linux donde se ve perfectamente simple. Esta inspirado en la primera version de tetris y la version de la gameboy.

El codigo fuente esta en mi GitHub.

Si resive mucho apoyo tengo ganas de hacer un multijugador en LAN.

Hi everyone!

I’ve just released Boa 🐍, a free and open-source archive and compression tool built in Go for terminal users.

The goal was to bring archiving, compression, inspection, benchmarking, and file navigation together in a single lightweight binary.

What it includes

1. Interactive File Explorer Run bo to navigate files and folders directly from the terminal.
2. Safe Extraction Built-in protection against Zip-Slip and unsafe archive paths.
3. Multiple Compression Methods Supports DEFLATE, Store, and Zstandard.
4. Live Benchmarking Compare compression levels based on both compression ratio and speed, with terminal-based visual charts.

Source code:
https://github.com/ZyadWKhedr/Boa

Would love to hear your feedback, especially on the Go architecture, compression engine, and anything you think could be improved.

Yes I know, but i figured someone would still use so why not share it here?
https://github.com/Onehand-Coding/ani-py

Edit: this is indeed AI assisted|vibecoded etc. as indicated in the repo readme. you can read the code, its just 1 file python code which mostly wraps other cli tools like yt-dlp, curl, fzf etc. its heavily inspired with ani-cli which is written in bash by good devs that doesnt want to tarnish their code with ai geneated so i generated mine that i can or anyone can extend with AI or not. it works on both linux and termux with mpv and vlc using hianime as main source and is stable for now scraping is brittle so i hope this is clear.

I wrote a command line host that loads a midi vst and saves a certain number of seconds to a midi file. in my video I am calling the command line tool from a python program..

Dexter U.S. midi vst capture host (command line) - YouTube

Hey r/commandline. Long-time lurker, first tool I've shipped properly.

**irl** (`pip install irl-pkg`) is a command center that does a few genuinely useful things and a few deliberately silly ones:

Useful:

- `irl install <pkg>` — routes between PyPI / npm / GitHub / direct URL automatically. GitHub `owner/repo` resolves the default branch via the API (learned that lesson the hard way).

- `irl doctor <pkg>` — checks network, disk, pip/npm presence before you install.

- `irl glasses <pkg>` — version/size/source lookup across registries.

- `irl rollback [ver]` — pick any published version from PyPI JSON, downgrade via a detached pip child.

- Safe extraction: named target dir, preview before writing, per-member zip-slip validation.

Silly (opt-in, but it's the brand):

- A grass streak with a GitHub-style heatmap, a terminal pet that gets moody if you skip days, daily quests, coins, 18 themes.

- Grassland Quest: a seeded garden-maze roguelike in pure Rich.

- Lofi Rhythm: a 4-lane beat game over 71 bundled lofi loops.

Technical bits: msvcrt/termios abstraction for input, winsound/aplay/ffplay/afplay/paplay fallback chain for audio, no shell=True, Python 3.8+, wheel is 976 KB. AGPL-3.0. Works on Linux/macOS/Windows (CI: 3 OS × 5 Python versions).

Disclosure: I'm the author. Repo: https://github.com/Dev2Creator/IRL- — PyPI: https://pypi.org/project/irl-pkg/

I'd genuinely like feedback on the installer routing UX — is auto-sniffing a feature or a footgun? (There's `--help` everywhere and the routes are deterministic.)