Migrate from Panes to Areas (can be moved and undocked)

[franknoirot]

Milestone for issue tracking: https://github.com/KittyCAD/modeling-app/milestone/22
Milestone contributors: @franknoirot

---

Our current layout looks like this:

The left sidebar and the toggle-able panes were migrated to a long time ago from a more sophisticated resizable, draggable area-based layout actually. However, this arrangement has caused some issues:

• Shift the scene view to make things remain visible when opening a pane #4538
• https://community.zoo.dev/t/allow-undocking-of-kcl-code-window/152
• Panes are not vertically resizable

We need a more flexible layout system, that allows for:

1. areas to be moved
2. areas to be broken out into new windows
3. layouts to be saved
4. the app to run fine with only the modeling pane, only the code editor, etc

In the broad strokes, Blender's Areas concept provides some good prior art on a layout methodology. I've attempted a single mockup of a "code pane and modeling pane only" layout as a starting point. I'll create more examples of different layouts to prove out the idea while we discuss.

[franknoirot]

As a part of this, I am thinking about the Feature Tree and how it fits into the broader layout vision.

Enabling this means finding the divides between Areas that can stand alone and making it possible to run the app without any others. I think that the Code Area, the Modeling Area, and the File Browser Area are good candidates, but I do not think the Feature Tree meets that criteria.

We have always held that the Code and Feature Tree are very much two sides of the same coin, and indeed they are. However, edit flows through the Feature Tree absolutely require the scene to make point-and-click selections. A user could, and I propose should, be able to open the app with only the Code Area open, or only the Modeling Area.

Furthermore, while we have talked about enabling multiple file buffers open at once, it would make no sense to open multiple "Feature Tree buffers" for the same reason. The Feature Tree is tied to one Modeling Area.

I also propose that this same coupling is true of the Variables and Logs panes. They are by their nature tied to the currently-viewed KCL file in the Modeling Area.

I think there is good prior art in the Blender docs for Panes within an Area, which they group into Regions. This would be considered a Panel Region I believe.

[jtran]

Yes, Variables and Logs are tied to the current execution. But it still might be nice to tear them off into their own area/region/window/floating toolbar to move them out of the way.

[franknoirot]

This is a good point @jtran.

[franknoirot]

Okay so I have two user flows that I want but cannot yet reconcile:

1. Ability to easily toggle "sidebar"-like areas similar to Obsidian, VS Code and Figma

Screenshare.-.2025-06-20.1_35_23.PM-compressed.mp4

2. Ability to create arbitrary layouts via splitting and merging areas similar to Blender

Screenshare.-.2025-06-20.1_37_41.PM-compressed.mp4

These two ideas feel incompatible in my mind but I'm trying to find an intuitive way to achieve both.

[franknoirot]

Okay so the reason that Blender can't have "toggle sidebar" buttons is because more than one split can occur at any given level. The sidebars and console pane of VS Code are kind of guaranteed areas.

[Irev-Dev]

My take is "Just combine the two approaches bro."

One thing I don't love about the blender approach is it strikes me as hard to quickly collapse some of your custom areas (maybe blender has a good way of doing this that I'm just un aware of.)

But I'm thinking why not just have the two side bars as dedicated areas that are always collapse/expandable, AND the user can customise them and put whatever they want in there, including splitting into multiple section, but they will remain as special, easy to collapse area.

The borders would have to be emphasise these are different from a regular area split.

wdyt

[franknoirot]

@Irev-Dev thank you for this idea it was laying right there! I'm still trying to pin this down but here's a sketch of what that might be able to look like, what do you think?

1. Sidebar buttons go on left and right sides of the app header
2. Sidebar areas are separated by 1px darker color, no border radius on outer sides
3. Splits within any of the 3 primary areas are separated by 1px of slightly less dark color, border-radius on all sides

[Irev-Dev]

I looked for 3s to see the "no border radius on outer sides" and couldn't figure it out. I'm sure if I look longer I'll figure it out, but this strikes me as not enough to show they're different, and the dark border is pretty dang subtle as well.

I mean I don't know how obvious it needs to be, maybe users will just figure it out, but gut says more obvious, I think other much more contrast differences in the border colours, or maybe hit 'em with a double line border or similar visually distinct pattern (zebra lol)

[franknoirot]

@lee-at-zoo-corp had a compelling idea mentioned in yesterday's Zoo Design Studio frontend meeting: with a conversational ML interface for agentic editing, it could be useful to have a ML area open alongside the home view, because the ML agent would be able to perform actions across projects. Since this discussion has only really been concerned with the modeling view having panes, it could be complicated if we need to support areas that persist across navigations to the home route.

[franknoirot]

Even if we allow area-style UX on the home page using the same mechanisms decided upon in this discussion for the modeling view, I think those layouts should be distinct between the views.

If the user has a ML area open on the modeling view and one on the home page layout (both could be persisted separately. We wouldn't have that "shiftless" experience that first popped into my head, where the project explorer swaps out with the modeling view while nothing else changes, unless the user's two layouts happened to be set up the same way, but that is fine, since many of the area types would not be usable on the home page route without a project context. They really are two different layouts, that happen to have one area type coming in the future that is usable in both.

I'm still very in favor of making a ML area openable from the home route, and persisting that layout config for the user.

[franknoirot]

I don't know if it's necessary that users go along for the ride when they send their ML agent to go do things like scaffold out a project on their behalf: that's the point of delegation, that they just go off and do those tasks while the user does other things.