Repository navigation
Replies: 2 comments 1 reply
|
I was also wondering whether to keep the native macOS tab window or use a custom in-app version. Using a native tab window means each tab is a separate window instance, which increases memory usage and significantly slows things down. I will revert and look into how to optimize this part. Thank you for your feedback. |
|
The tab bar went back to native window tabs in 0.32.1, the day after this post. Since 0.65.0 one window holds every connection, and native tabs can only show one set of tabs per window, so each connection's tabs live in an in-app strip drawn to the system tab bar's geometry. Window tabs still work for whole windows (Window > Merge All Windows). If something in the current strip still feels off next to the system bar, please open an issue with what you see. Closing as outdated. |
Uh oh!
There was an error while loading. Please reload this page.
The new tab bar is not as polished or usable as the native one. While the performance improvement is appreciated, the native tab experience integrates much better with macOS (appearance, behaviors, expectations). The new tab bar looks less consistent with the system and feels less refined overall.
Maybe the native version felt slow not because of the tab bar itself, but because of the content it has to render. It’s possible that macOS waits for a tab’s content to be ready before switching, which could make the UI feel sluggish. If that’s the case, an alternative approach might be to keep native tabs but defer or lazily load the tab content after the switch. This could preserve the native look and feel while addressing the performance issue.
Thanks for this amazing software though !
All reactions