Explore alternative browser configurations

[claude]

While our current browser looks and acts like a smalltalk browser, which I like, I find that it doesn't feel as natural as some of the other vs code windows. I'd like to explore alternatives to the traditional code browser in smalltalk focusing especially on the two major operations - navigation and editing.

Goals:

• Maximize use of the existing VS code tools where appropriate for a more vs-code like experience.
• Minimize dangling windows like source editors that get misplaced or left around.
• Make the navigation feel as close to traditional smalltalk as possible. (if possible)
• Explore "out there" ideas to see what's possible.
• Limit highly nested trees

@jfoster proposed this idea as an exploration topic in a private slack message:

"Regarding VS Code navigation, one idea is a new View Container in the Secondary Side Bar (like our existing GemStone in the Primary Side Bar). Then you could add one or more Tree Views (each could simply hold a list if a tree was not appropriate). Then the side bar could be shown or hidden as desired."

---

Migrated from GitLab: GemStone/grail#60

[ericwinger]

Closing — this exploration happened, and its outcome is the GemStone Explorer.

@jfoster's proposal is essentially what shipped: a dedicated view container holding several sibling tree views, each a flat list where a tree wasn't the right shape, shown or hidden as a unit. It landed in the activity bar / primary side bar rather than the secondary side bar, but the structure is the one he described. package.json contributes the gemstoneExplorer container with six views:

View	Shape
Dictionaries	list
Class Categories	list
Classes	list
Hierarchy	tree (where nesting is the actual information)
Methods	list
Open Editors	list

Against the goals in the description:

• Maximize use of existing VS Code tools. Source opens in real VS Code text editors through the gemstone:// FileSystemProvider, so find/replace, the LSP features, diffs, breadcrumbs and the editor history all work natively instead of being reimplemented in a webview. Search moved the same way — GemStone Search (Need Omni Search #378) is a docked panel view on the panel strip next to Terminal and Output.
• Minimize dangling windows. OpenSourceMode in client/src/gemstoneExplorer.ts is 'preview' | 'keep' | 'pin': a single click navigates into VS Code's own reusable preview tab, a double click promotes it in place to a permanent tab, and pinning is explicit. So browsing a hundred methods no longer leaves a hundred tabs behind — the transient-tab bookkeeping is VS Code's, not ours.
• Navigation close to traditional Smalltalk. The Dictionaries → Categories → Classes → Methods pane chain is the classic four-pane browser flow, with Hierarchy alongside it, just decomposed into sibling views instead of one nested tree.
• Limit highly nested trees. That decomposition is the point — five of the six views are flat lists; only Hierarchy nests, because there the nesting is the content.
• Explore "out there" ideas. GemStone Search (Need Omni Search #378) came out of the same thinking: one query field over provider-per-category fan-out across classes, methods, dictionaries, globals, source and literals — Spotter/Search-Everywhere rather than anything a Smalltalk browser ever had.

Related work that came out of this direction: #421 hid the System Browser button on session rows so the Explorer is the discovered default, #427 added SUnit test running to the Explorer, and #478 is in flight with editor-breadcrumb class navigation, Go Back/Forward across viewed methods, and Methods-pane discoverability fixes (it also retires the Open Editors pane in favour of a status-bar close-all, so the table above will be five views once it merges).

#289 stays open for the remaining Browser convergence work — folding the System Browser and the Explorer onto one shared backend. This issue was the open-ended "explore alternatives" question, and that question is answered; anything further is concrete convergence work, tracked there.