Skip to content

Conversation

@tidely
Copy link
Contributor

@tidely tidely commented Nov 4, 2025

Closes #ISSUE

Removes a few eager container clones and iterations.

Added a todo to get_prev_tab_group_window and get_next_tab_group_window. They seem to use HashMap::keys() for choosing the previous tab group, however .keys() returns an arbitrary order, so I'm not sure if previous actually means anything here. Conrad seems to have worked on this part previously, maybe he has some insights. That can possibly be a follow-up PR, but I'd be willing to work on it here as well since the other changes are so simple.

Release Notes:

  • N/A or Added/Fixed/Improved ...

We unnecessarily looked for the group id and then looked it up in the
hashmap, when we could iterate through the group right away
@cla-bot cla-bot bot added the cla-signed The user has signed the Contributor License Agreement label Nov 4, 2025
@JosephTLyons
Copy link
Collaborator

Thanks for the PR @tidely, we'll check it out.

}

/// Get all tabs in the same window.
pub fn tabs(&self, id: WindowId) -> Option<&Vec<SystemWindowTab>> {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This has become such a small helper that I'd consider removing it entirely. It's only called a few times and the majority of the time, we use .position() right after to find the index of tab with the right WindowId. Which could be done right away instead of using the helper first, thus removing an iteration through the values.

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

Labels

cla-signed The user has signed the Contributor License Agreement community champion

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants