Scanning list shows nothing when the terminal is short
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 3k
- Forks
- 79
- PR merge metrics
- No merged PRs in 30d
Description
I spent a good while thinking my bluetooth adapter was broken. The scanning list in bluetui was
completely empty, while scanning over D-Bus at the same time found around 30 devices. The devices
were being discovered fine. There was just no room left on screen to draw them.
My terminal was 21 rows and I have 7 paired devices.
In App::render in src/app.rs:
let paired_devices_block_height = selected_controller.paired_devices.len() as u16 + 4;
...
Layout::vertical([
Constraint::Length(paired_devices_block_height),
Constraint::Fill(1),
Constraint::Length(adapter_block_height),
Constraint::Length(2),
]).margin(1)
The paired devices block asks for a hard Length that grows with how many devices you have
paired, so it always gets what it asks for. The scanning block is Fill(1), so it only gets the
remainder, and the remainder can be zero.
With 7 paired devices that is 11 rows for the paired list, 5 for the adapter, 2 for help and 2 for
the margin. So 20 rows are gone before scanning gets anything, and it needs 4 more for its borders
and header before it can show a single device. Below 24 rows you see nothing at all.
Here is what actually rendered at different terminal heights, with a scan running the whole time:
| terminal rows | devices shown |
|---|---|
| 24 | 0 |
| 25 | 1 |
| 28 | 4 |
| 30 | 6 |
| 36 | 12 |
| 45 | 19 |
The part I think matters most is that the cutoff depends on how many devices you have paired.
With 15 paired devices you would need 32 rows. So this gets worse the longer someone uses bluetui,
and it is invisible if you test with a tall terminal or an adapter with nothing paired to it yet.
I wondered if that is why #14 could not be reproduced, though I have no way to know for sure.
What made this hard to figure out is that there is no scrollbar and no other hint that anything
was found, so an empty list looks identical to a broken adapter. I went digging through rfkill,
firmware logs and PipeWire before it occurred to me to make the window taller.
Would you be open to capping the paired devices block so the scanning block always keeps enough
room for at least one row? The paired table already has a scrollbar for when it runs out of space,
so it would degrade the same way the adapter table already does. I have a patch that does this and
changes nothing at sizes that already fit. Happy to open a PR if you want it.
One thing I am unsure about: if the terminal is too short for both lists, which one should win? My
patch keeps the paired list visible, but when a scan is running the scanning list is probably what
you are actually looking at.
Environment
- bluetui 0.8.1
- Arch Linux, kernel 7.1.5
- kitty 0.48.2, window was 21 rows tall
- bluez 5.87
- 7 paired devices at the time
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in src/app.rs at App::render and inspect how the paired-devices and scanning blocks share terminal height. Reproduce the reported behavior with short terminal sizes and several paired devices, then verify that scanning retains room for at least one row while the paired table can use its scrollbar and existing fitting sizes remain unchanged.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux, rust
- Domain
- cli, operating-systems
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 76/100