Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove the additional explicit wait "hack" in progress bar #163

Open
cardil opened this issue Mar 22, 2024 · 4 comments
Open

Remove the additional explicit wait "hack" in progress bar #163

cardil opened this issue Mar 22, 2024 · 4 comments
Labels
kind/bug Categorizes issue or PR as related to a bug. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. triage/accepted Issues which should be fixed (post-triage)

Comments

@cardil
Copy link
Contributor

cardil commented Mar 22, 2024

The additional explicit wait "hack" in the progress bar should be removed. If your UI has a lot of progress bars, this wait will be visible.

func (b *BubbleProgress) quitSignal() tea.Cmd {
// The final pause is to give the progress bar a chance to finish its
// animation before quitting. Otherwise, it ends abruptly, and the user
// might not see the progress bar at 100%.
return tea.Sequence(b.finalPause(), tea.Quit)
}

But, I don't see a way, with the current API of bubbles' progress, to achieve it otherwise...

Without the wait, we get UI with progress bars that are never 100% completed. See example: #162 (comment)

Originally posted by @cardil in #162 (comment)

@cardil
Copy link
Contributor Author

cardil commented Mar 22, 2024

I don't think it is possible with the current API. When the tea.Quit command is handled, the Bubbletea's renderer stops, and restores the terminal to standard output mode. So, you can't replace the line that was already written.

I think the Bubbletea should allow defining the last tea.Quit state, that will be printed just before the exit, and without waiting for the animation loop to draw it.

@cardil
Copy link
Contributor Author

cardil commented Mar 22, 2024

/kind bug

@knative-prow knative-prow bot added the kind/bug Categorizes issue or PR as related to a bug. label Mar 22, 2024
Copy link

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jun 21, 2024
@dsimansk
Copy link
Contributor

/remove-lifecycle stale

@knative-prow knative-prow bot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jun 21, 2024
@dsimansk dsimansk added lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. triage/accepted Issues which should be fixed (post-triage) labels Jun 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. triage/accepted Issues which should be fixed (post-triage)
Projects
None yet
Development

No branches or pull requests

2 participants