Color LED tab

[ArisMorgens]

No description provided.

[Copilot]

Pull request overview

This PR enables the Color LED tab in the UI and migrates its Crazyflie interactions to the newer async cflib2-style APIs (async params + log streaming), aligning it with the newer connection model used by other tabs like ParamTab.

Changes:

• Enabled ColorLEDTab in the tab loader (available list + import).
• Reworked Color LED deck detection, param writes, and thermal throttling monitoring to use async cflib2 calls and create_task() scheduling.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File	Description
src/cfclient/ui/tabs/__init__.py	Uncomments/imports ColorLEDTab and adds it to the available tab list so it can be loaded.
src/cfclient/ui/tabs/ColorLEDTab.py	Migrates to async cflib2 param/log APIs, adds async connection setup, and implements thermal log stream reading via background tasks.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[gemenerik]

Custom colors are not grayed out when disconnected. (They may not have been in the old client, but anyways)

[ArisMorgens]

Nice catch! This issue exists in the old client as well. It is fixed for the new client in 0ae1059.

[gemenerik]

Several places replace specific exception types with bare except Exception. The risk here is that it hides; programming mistakes, unexpected runtime issues, new exception types from cflib2. They would all be silently logged as a debug message while the code moves on. It's better to catch only the exceptions you actually expect.

[gemenerik]

not this pr but this feels fragile

[ArisMorgens]

Fixed in 3530d38.
Instead of retrieving a button's color by reading its stylesheet, we now store the color directly on the button using Qt's setProperty(). This happens both on preset buttons once during connection, and on custom buttons when they're created.

[ArisMorgens]

Several places replace specific exception types with bare except Exception. The risk here is that it hides; programming mistakes, unexpected runtime issues, new exception types from cflib2. They would all be silently logged as a debug message while the code moves on. It's better to catch only the exceptions you actually expect.

I replaced the broad except Exceptions with specific ones from cflib2.error in e3833c2. I tried to match the exception with the relevant errors from each call (e.g. detect_decks() calls cf.param().get(), so I used ParamError). @gemenerik Is this the appropriate approach of catching the expected exceptions?

[gemenerik]

Still has this potentially fragile parsing. Again not this PR but maybe nice to fix.

[ArisMorgens]

In 6994368 I replaced the chained split() with a regex that explicitly targets the QPushButton{} block, so the parsing should be more robust now. What do you think @gemenerik?

[gemenerik]

Revisiting my earlier comments: I focused on broad catches, but the real question is whether to catch at all. Errors can occur in all of these places, but we should only catch one when there's something useful we can do about it. Otherwise the catch just hides the problem. Concretely:

• _run_thermal_stream: remove the try/except entirely. next() only raises DisconnectedError, which create_task's done callback already treats as a normal disconnect.
• start_monitoring: remove the LogError catch.
• Color fetch: remove the ParamError catch (the deck was already detected, so the param must exist).
• detect_decks: check param_name in cf.param().names() instead of catching ParamError. A missing deck param is a normal case with a clear answer (no deck), so it doesn't need an exception.

[ArisMorgens]

Revisiting my earlier comments: I focused on broad catches, but the real question is whether to catch at all. Errors can occur in all of these places, but we should only catch one when there's something useful we can do about it. Otherwise the catch just hides the problem. Concretely:

* _run_thermal_stream: remove the try/except entirely. next() only raises DisconnectedError, which create_task's done callback already treats as a normal disconnect.

* start_monitoring: remove the LogError catch.

* Color fetch: remove the ParamError catch (the deck was already detected, so the param must exist).

* detect_decks: check param_name in cf.param().names() instead of catching ParamError. A missing deck param is a normal case with a clear answer (no deck), so it doesn't need an exception.

This sound like a good way forward to me. Fixed in c1f3307.

[gemenerik]

Nice work!