Skip to content

feat: add runtime display for selected service#61

Merged
matheus-git merged 1 commit intomatheus-git:runtimerfrom
reidt1:runtimer
Feb 15, 2026
Merged

feat: add runtime display for selected service#61
matheus-git merged 1 commit intomatheus-git:runtimerfrom
reidt1:runtimer

Conversation

@reidt1
Copy link
Copy Markdown
Contributor

@reidt1 reidt1 commented Feb 13, 2026

Thought it might be cool to have the runtime for the selected service running in the top right. I don't know rust too well, but I can try to accommodate some changes if you're interested or feel free to make changes you like.

Screenshot 2026-02-12 at 23 56 40

Show the active runtime of the currently selected service in the top-right of the list view. The timestamp is fetched via D-Bus (ActiveEnterTimestamp) and ticks once per second while a service is active.

  • Uses recv_timeout(1s) in the event loop instead of a background redraw thread, keeping idle CPU usage near zero when no active service is selected or in Log/Details views.
  • Only shows runtime for services in the "active" state; stopped/failed services display "Runtime: inactive".
  • Timestamp cache is invalidated after service actions (start/stop/ restart/enable/disable/mask) so the display refreshes immediately.
  • Uses LoadUnit to resolve the unit object path in a single D-Bus call instead of ListUnitsByNames.

@matheus-git
Copy link
Copy Markdown
Owner

@reidt1

Thank you for your interest in contributing to the project, I really appreciate the initiative.

I don’t think it’s very intuitive for the runtime to appear at the top right, especially since there isn’t a clear pattern if we want to add more information there later. Ideally, the runtime should appear in a dedicated "Runtime" column. However, since ratatui re-renders the entire screen whenever something changes (it doesn’t update just a specific section), the column values would need to be static.

That’s why I was thinking about simply displaying the date and time when the service was started instead. What do you think?

If you have any suggestions regarding the implementation, please let me know. Otherwise, could you please update the pull request to target the runtimer branch instead?

@reidt1
Copy link
Copy Markdown
Contributor Author

reidt1 commented Feb 13, 2026

@matheus-git

Very cool project you have, and thanks for sharing it with everyone! I'll update the PR now as well.

Fair point calling out the location. Probably better for something non-service related, like a tool feature. I think another column would be pushing it for some small to medium terminal window sizes, or at least runtime might not deserve its own.

Instead of another Runtime column, what do you think about overriding the highlighted Active column cell to show runtime for active services? (demo below). And do you prefer static values? or live ones like seen at the end of the video?

Screen.Recording.2026-02-13.at.08.51.28.mov

@reidt1 reidt1 changed the base branch from main to runtimer February 13, 2026 15:10
@matheus-git
Copy link
Copy Markdown
Owner

@reidt1 That’s cool and very useful, thanks.

Whether the time should be static or not is a matter of preference, but having a dynamic runtime for active units sounds good.

Show the active runtime of the currently selected service in the
list view. The timestamp is fetched via D-Bus (ActiveEnterTimestamp)
and ticks once per second while a service is active.

- Uses recv_timeout(1s) in the event loop instead of a background
  redraw thread, keeping idle CPU usage near zero when no active
  service is selected or in Log/Details views.
- Only shows runtime for services in the "active" state.
- Timestamp cache is invalidated after service actions (start/stop/
  restart/enable/disable/mask) so the display refreshes immediately.
- Periodically re-fetches timestamp (30s) to handle external restarts.
- Uses LoadUnit to resolve the unit object path in a single D-Bus
  call instead of ListUnitsByNames.

Signed-off-by: Reid Tonking <Reid.Tonking@gmail.com>
@reidt1
Copy link
Copy Markdown
Contributor Author

reidt1 commented Feb 14, 2026

@matheus-git let me know what you think of the current changes. I had to change some ANDed "let" statements to nested ifs to get it to build (a nightly vs stable rust thing?).

@matheus-git
Copy link
Copy Markdown
Owner

@reidt1

It looks good, I can approve the PR if you're satisfied with it. Later, I plan to add the same timestamp for the failed ones (how long ago it failed), and format the active ones as:

"Active: {time} ago"

By the way, what did you think of the code? Where did you have the most difficulty? What could I improve to make it easier for others to contribute?

@reidt1
Copy link
Copy Markdown
Contributor Author

reidt1 commented Feb 15, 2026

@matheus-git I'm happy with it if you are. I like that idea for the failed services. The number of characters for the Active column might start getting a bit too long with something like "Active: 14d 12h 57m 23s ago", but maybe you could truncate the time or something depending on what wording you end up choosing.

I think it looks pretty clean. Since I'm new to rust and terminal UI stuff, I had AI help me look over the project structure and figure out where things should go and I had no problems there. The only thing I would suggest is adding some kind of integration testing

@matheus-git matheus-git merged commit 7d98c21 into matheus-git:runtimer Feb 15, 2026
@matheus-git
Copy link
Copy Markdown
Owner

Thank you for contributing.

@matheus-git
Copy link
Copy Markdown
Owner

@reidt1 I hadn’t noticed this before because my new processor is fast, but the TUI is slow to start because it freezes before rendering while executing the timestamp search. Ideally, this should happen in a separate thread so the TUI doesn’t freeze. Implementing this thread isn’t trivial, even though there’s already an example with spawn_query_listener(). There would also be issues when the user scrolls through the list, potentially triggering multiple requests. Anyway, what do you think?

@reidt1
Copy link
Copy Markdown
Contributor Author

reidt1 commented Feb 16, 2026

@matheus-git Hmm, I'm unable to recreate the issue on my machine to see the effects, but I understand the issues. I submitted a new Pull Request if you'd like to take a look and test it.

If you want to make a persistent dev or next branch or just a temp branch for this, I'll switch the PR that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants