Add activity cooldown indication - #2334
Conversation
Highlight the title of a background tab (bold + orange) when its terminal produces output, clearing once the tab is selected. Gated behind a new "display-tab-activity" setting, off by default. To avoid lighting up every tab on session restore, activity is ignored for adjustable grace periods: a new-tab grace (default 3s) starting at tab creation, and a shorter focus-loss grace (default 1s) when a tab loses focus. The focus-loss grace never shortens an existing longer grace, so the rapid switch-page cascade during restore can't clobber the creation grace. Both periods are configurable in Preferences > General. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Fade a highlighted tab from active (orange) to stale (blue) once tab-activity-cooldown seconds pass with no new terminal output, so long-quiet tabs are visually distinct from tabs with fresh activity. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Davidy22
left a comment
There was a problem hiding this comment.
Sorry about the delay, been busy. There's been a fair few changes, you'll have to rebase on top of the current master. Also some strange meta changes that you shouldn't need to do here, and one baffling change. If you're involving AI, it would be much preferred if you could also review the output the AI is giving you
There was a problem hiding this comment.
There is a mental/usability cost to every setting that we put in the preferences menu, these seem like settings that people aren't going to actually touch. Like I'd say the colors would be more likely to be touched than these times, and even then probably unlikely. Can just trim it down to the checkbox.
| @@ -640,14 +640,17 @@ def remove_dead_child(self, child): | |||
| # Foreground color applied to a background tab's title when it has unseen | |||
| # activity. Chosen to stay readable on both light and dark tab bars. | |||
| TAB_ACTIVITY_COLOR = "#E8A33D" | |||
There was a problem hiding this comment.
Usually constants like this should go at the top of the file, but also these are only getting used once so they may be better named inside _render() where they're used.
|
|
||
| def _render(self): | ||
| if self._activity: | ||
| if self._activity_state == "active": |
There was a problem hiding this comment.
Generally better to use enums for nonbinary states instead of strings
| cooldown elapses. A single shared timer is used regardless of how | ||
| many tabs are currently highlighted.""" | ||
| if self._activity_timer_id is None: | ||
| self._activity_timer_id = GLib.timeout_add(1000, self._tick_activity_states) |
There was a problem hiding this comment.
Why are we doing it this way? The timeout call lets you just set the time. Is it to reduce tick calls? I mean, with a 30 second cooldown you'd need to have stuff happening in more than 30 tabs for this to be savings.
There was a problem hiding this comment.
Don't touch unrelated reno files even if you're hardly changing anytthing
| @@ -0,0 +1,25 @@ | |||
| release_summary: > | |||
There was a problem hiding this comment.
Put everything you want to say in one reno file
There was a problem hiding this comment.
What on earth are you doing here?
There was a problem hiding this comment.
Otherwise it doesn't work even in venv for my python 3.12.3...
The keybinder library's XKB modifier computation (FinallyGetModifiersForKeycode) spuriously returns Mod1/Alt as a consumed modifier for F12 at level 0 on certain systems (e.g. Cinnamon/Muffin). This causes XGrabKey to attempt grabbing Alt+F12 instead of plain F12, which fails because the X server reserves Alt+Fn keys for VT switching. Disabling cooked accelerators matches the approach used by Tilda terminal's tomboykeybinder.c, which does not use XKB at all for modifier computation. Users who need cooked accelerators can re-enable them via GSettings. sem-ver: bugfix
Allows command to work for relative paths, including partial ones. sem-ver: bugfix
button_press() handled Ctrl+click but returned None, so the event kept propagating and VTE's default handler also forwarded it to the child process as a mouse report. Any mouse-aware application then acted on the same click, e.g. a terminal multiplexer that opens links itself ended up opening the very same URL a second time. Return True only when one of the Ctrl+click branches actually handled the event, so an unhandled Ctrl+click still propagates and Ctrl+drag block selection and Ctrl+click inside mouse-aware applications keep working. sem-ver: bugfix
…uilds and fix some pylint stylings
zhum
left a comment
There was a problem hiding this comment.
Updated PR according to the comments.
Added new tab indication: if there was activity, but then it stopped and no changes happened for 30 seconds (may be changed in settings), tab color is changed to blue.