Horizontal settings tabs

[dlab-anton]

Context

I understand there is work ongoing to refactor Settings into a pop-out tab which may be awesome. In the mean-time I wanted to push this to mull over.

To improve Settings information presentation, I chose to implement horizontal tabs. Such a separation of concerns is especially good for new users. For advanced users this should also speed up navigation.

The challenge is primarily to go vertical or horizontal tabs. However here I am specifically avoiding a left-column layout which would clash with VS Code's own Activity Bar, resizable panels, and dev preference for maximizing horizontal space. Since these tabs can overflow in narrow sidebars, I enabled standard horizontal scrolling via mouse wheel and trackpad gestures but hid the native scrollbar using CSS for a cleaner look. To enhance navigation, clicking a tab now triggers an instant auto-scroll (behavior: 'auto') that reliably centers the active tab; This makes it very quick for advanced users to reach the right tab. Finally, I kept the "More" dropdown as an alternative quick-access method for all settings sections but repositioned it into a standard / more coherent UI pattern.

Tab Navigation Structure:

• Implemented horizontal tabs using a combination of React components and CSS
• Each settings section (providers, auto-approve, browser, etc.) is now a separate tab
• Added auto-scrolling to center the active tab when selected

Scrolling Mechanisms:

• Implemented mouse wheel support for horizontal scrolling
• Hidden scrollbars for a cleaner UI while maintaining scroll functionality

Overflow Menu:

• Re positioned at the right side of the tab bar for easy access

Implementation

Technical Implementation

The tabs are implemented using the following approach:

Component Structure:

• Using React's TabList, TabTrigger, and TabContent components from a common Tab component library
• Each tab is defined in an array of section objects with IDs and icons
• State management with useState to track the active tab

Scrolling Implementation:

• Container uses CSS overflow-x: auto with hidden scrollbars via custom utility classes
• Tabs have flex-shrink: 0 to prevent compression in the flex container
• Custom wheel event handler translates vertical wheel movement to horizontal scrolling.

Auto-Centering Logic:

• Uses useRef to store references to each tab DOM element
• When active tab changes, uses scrollIntoView with specific options.

Implemented using DropdownMenu component

• Always visible at the right side of the tab bar
• Contains the same items as the tab bar for quick access

Styling:

• CSS classes defined in styles.ts for consistent tab styling
• Uses utility function cn() to combine multiple class names

How to Test

2. Settings page
3. Scroll horizontal with mouse wheel
4. Click edges for auto scroll
5. Overflow dropdown choice should also auto-scroll
6. Leave Settings page and come back and everything should still work
7. Should be very responsive/snappy/no lag

---

Important

Implement horizontal tabs in settings with auto-scrolling, mouse wheel support, and overflow handling.

• Behavior:
  • Implement horizontal tabs in SettingsView.tsx using TabList, TabTrigger, and TabContent.
  • Add auto-scrolling to center active tab and mouse wheel support for horizontal scrolling.
  • Maintain "More" dropdown for overflow tabs.
• Components:
  • Update Tab.tsx to include TabList and TabTrigger components with selection logic.
  • Modify SettingsView.tsx to manage active tab state and handle unsaved changes.
• Tests:
  • Add tests in SettingsView.test.tsx for tab navigation, unsaved changes dialog, and dropdown menu.
• Styles:
  • Add CSS classes in styles.ts for tab styling and scrollbar hiding.
  • Update settings.json for new tab labels and tooltips.

^{This description was created by for 02ee4b7. You can customize this summary. It will automatically update as commits are pushed.}

[changeset-bot]

⚠️ No Changeset found

Latest commit: 02ee4b7

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[ellipsis-dev]

Hello @dlab-anton,

Thank you for your contributions! After reviewing the pull request, it seems that the changes related to prompt variable interpolation (in src/core/prompts/sections/custom-system-prompt.ts and src/core/prompts/system.ts) could be separated from the UI improvements in the settings tabs. Splitting these changes into separate pull requests could help in focusing the review process and ensuring each set of changes is thoroughly evaluated.

Please consider creating a separate pull request for the prompt variable interpolation changes. Let me know if you have any questions or need further assistance.

Best regards,
Ellipsis

[ellipsis-dev]

Consider replacing the as any cast with a more precise type (e.g., Partial<Record<SectionName, HTMLButtonElement>>) for stronger type-safety.

Suggested change

	const tabRefs = useRef<Record<SectionName, HTMLButtonElement | null>>({} as any)
	const tabRefs = useRef<Partial<Record<SectionName, HTMLButtonElement>>>({})

^{This comment was generated because it violated a code review rule: mrule_QkEwsCio7v34DaCF.}

[sachasayan]

This looks great. I was thinking about something similar. I'll throw it out here: Thoughts on a phone-style settings area?

[dlab-anton]

This looks great. I was thinking about something similar. I'll throw it out here: Thoughts on a phone-style settings area?

The main difference is with horizontal tabs navigation is always present; so difference in navigation speed and discoverability. Because on the mobile settings layout you need to go 'Back' to see Settings list.

[sachasayan]

The main difference is with horizontal tabs navigation is always present; so difference in navigation speed and discoverability. Because on the mobile settings layout you need to go 'Back' to see Settings list.

Agreed. Though I'm thinking (could be wrong here) most people use Roo Code as as narrow sidebar (as you said) taking up very little real horizontal real estate. If most of the options end up in the overflow menu, then you haven't saved many clicks. Also thinking ahead to when we might have searchable settings, like Android and iOS both currently have.

One question: I haven't checked out your branch yet, but if you're all the way on the 'right' end of things (say, About Roo Code) how do you get back to the 'left' end? Is the toolbar horizontally scrollable?

Overall I think I really like this PR and I think it's a great first step to wrangling the settings nightmare — I want to fast-track this if there are no usability problems!

Are there any personal concerns with it you'd bring up?

[dlab-anton]

Agreed. Though I'm thinking (could be wrong here) most people use Roo Code as as narrow sidebar (as you said) taking up very little real horizontal real estate. If most of the options end up in the overflow menu, then you haven't saved many clicks.

Very good points. It is true horizontal tabs may only show ~2 to 6 tabs at a time on average, which is less than 50% the total.

If we define most narrow viewpoint at around 50 chars in the text field. Then, it shows about two tabs at a time:

We can compare this with vertical tabs.

On vertical tabs you have good persistence and discoverability. Collapsed mode to icons + tooltips may be an acceptable compromise for narrow screens.

Compare to mobile settings drill-down:

While the drill-down pattern is effective for mobile or very narrow views, Roo Code primarily targets VS Code on desktop. Many desktop users configure their sidebar with sufficient width to easily accommodate vertical tabs. In this common scenario, vertical tabs offer superior usability due to direct, one-click switching between sections, which is more efficient for desktop workflows than the two-step 'Back-and-select' process of drill-down. Prioritizing this faster navigation makes vertical tabs the better fit for our desktop users.

Also thinking ahead to when we might have searchable settings, like Android and iOS both currently have.

If we are only talking about UI elements I believe either tabs or drill-down can accommodate search well.

One question: I haven't checked out your branch yet, but if you're all the way on the 'right' end of things (say, About Roo Code) how do you get back to the 'left' end? Is the toolbar horizontally scrollable?

Yes the horizontal tabs have an auto-scroll centering, so you can navigate by clicking on the edge buttons (my preference) or you can use mouse-wheel.

Overall I think I really like this PR and I think it's a great first step to wrangling the settings nightmare — I want to fast-track this if there are no usability problems! Are there any personal concerns with it you'd bring up?

My personal concerns are that the code may carry technical debt due to it being generated with Roo, for example I need to edit tests.

[dlab-anton]

@sachasayan After consideration I would like to pivot to vertical tabs, there are some trade-offs but I think vertical tabs has max benefit for max users in this case. I'm very much open to feedback still.

[dlab-anton]

I'm going to close this pull and focus on vertical tabs instead: #2914

[sachasayan]

@dlab-anton Love the deep dive here. Thanks for doing this. Agreed, vertical tabs seems much better. I still think the way to go is going to end up an iOS-style settings area but that's on me to explore, and I think this is a great improvement.