Skip to content

Add ProgressBar::visual_index and clarify meaning of ProgressBar::index.#784

Open
chris-laplante wants to merge 3 commits intomainfrom
cpl/visual-index
Open

Add ProgressBar::visual_index and clarify meaning of ProgressBar::index.#784
chris-laplante wants to merge 3 commits intomainfrom
cpl/visual-index

Conversation

@chris-laplante
Copy link
Copy Markdown
Collaborator

MultiProgress::insert lets users insert a progress bar at a specified position within the MultiProgress. Before this PR, there was no way (besides keeping track manually) to know the position within the MultiProgress of a ProgressBar.

The ProgressBar::index method would be tempting if pub, but not appropriate because it refers to the opaque index within the MultiState's data structures. This PR also clarifies its documentation.

Something else that this PR enables is that users can now write their own insert_after_with_offset (as suggested in #724 (comment)), i.e. mp.insert(other_pb.visual_index() + offset, pb)

Supersedes #782 and #724

We no longer intend to expose this method as pub, but we should still
give it better documentation.
Comment thread src/progress_bar.rs

/// If this [`ProgressBar`] is a member of a [`MultiProgress`](crate::MultiProgress), then return visual position
/// on screen. Otherwise, `None`.
pub fn visual_index(&self) -> Option<usize> {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think there's value in wrapping this up in a newtype VisualIndex? In some future we might be able to then use that in InsertLocation variants...

Or maybe, should this just be named index and we rename the private method to something else (members_index() maybe)?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the second option - I'll work on it later this weekend/Monday. In that case, I would still suggest we newtype the "members index" type, so that we don't accidentally get them confused internally either.

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