feat: workspaces

[dalechyn]

What if I as a GPT power user never want to leave flux?

Abstract

Workspaces would enable users to manage multiple Conversation Trees in one organized space, to easily navigate between them.

Problem

Project-specific AI tasks:

1. I generate ideas –> I want to add some degen input from GPT –> Creating a tree for Idea Iterations & Enhancing;
2. I manage projects –> I want GPT to write the issues for me, following my guidelines –> Creating a tree for GitHub Project Management;
3. I have a specific stack of frameworks & tools I build with –> I want GPT to help me with writing boilerplate and fixing my stuff (davinci is better for such things, but hey GPT is multimodel) –> Creating a tree for Code Helper

Some can have a shared context with a connection to a Parent Node, or not.

There could be a code-specific context that is intended to be shared across some of the projects, but with such a setup, things would get messy as I as a user would need to move those nodes around to compose them in "groups" at least visually.

Specification

• There can be $1...W$ workspaces;
• Workspace can hold $1...N$ nodes;
• Workspace does not require nodes children or parent to be in the workspace too;
• Visually represented as a circle-edged rectangular with dash-stroke.
• Navigation between them is done via Shift+Cmd+<Left Arrow> and Shift+Cmd+<Right Arrow>.
• Workspace can have a name (cc feat: rename nodes #8)

[transmissions11]

hmmm interesting i saw the word workspaces and thought one thing (basically distinct tabs in flux that couldn't interact) but (correct me if i'm wrong) it sounds like you're describing basically a way to group nodes together into one big proxy node, and then play with the proxy nodes in some higher order graph view?

this feels a bit convoluted to me UX and implementation wise— but interesting — got some initial questions:

• When a tree is grouped into a "workspace" what edge is used for nodes that connect to it?
• Why do you propose two navigation keybinds of different directions if there's no inherit directionality to workspaces? Are you implying there should be a horizontal scroll view of tabs at the bottom of the screen as well?

[dalechyn]

it sounds like you're describing basically a way to group nodes together into one big proxy node, and then play with the proxy nodes in some higher order graph view?

YESSS! Pretty much like yarn/pnpm workspace brought to flux.

• When a tree is grouped into a "workspace" what edge is used for nodes that connect to it?

Not sure to understand it correctly. As I see it, workspaces cannot connect with the nodes, thus having no edges (if I correctly understand "edge" as a term).

Why do you propose two navigation keybinds of different directions if there's no inherit directionality to workspaces? Are you implying there should be a horizontal scroll view of tabs at the bottom of the screen as well?

Indeed, you're right. Workspaces are not nodes and won't have the same tree-style navigation as nodes do.

I think of workspaces more as layouts that group nodes, and enable effective navigation between themselves.

About the horizontal scroll view, that most probably will end up with a bad UX, I think making it a vertical scroll view with Cmd+Shift+ArrUp and Cmd+Shift+ArrDown would be better.

We could render 4 workspaces at once in a vertical scroll, and blur the rest.

I think it could be a good place to play with:

[dalechyn]

https://reactflow.dev/docs/examples/nodes/dynamic-grouping/
cc @transmissions11

[transmissions11]

Not sure to understand it correctly. As I see it, workspaces cannot connect with the nodes, thus having no edges (if I correctly understand "edge" as a term).

oh so u dont want to be able to connect workspaces n stuff? what value do u get from just having like lone blocks that you can double click vs just having a bunch of tabs

reactflow.dev/docs/examples/nodes/dynamic-grouping

this isnt what you actually want tho is it? i just dont see how this is useful

[transmissions11]

sorry i think im likely misintepreting/strawmanning you. any chance you'd sketch out what you mean a little further w/ like ms paint or something silly

[dalechyn]

Okay, let me start this from scratch.

Problem:

It's hard to navigate between multiple trees within the same playground.

As a user, I have to memorize that i.e., Tree that is set up for code completion is at the left top corner, Tree that helps out with tax filling is at the right top corner, Tree that tries to teach GPT that PUSH0 is more expensive than CALLVALUE to put 0 to stack under some conditions, etc.

Moreover, some Trees can be context-specific themselves, just not bound by GPT Prompt. Example:

Solution:

We can think of different shortcuts, I guess numerical ones are better since it's not as tree navigation with Cmd+Arrows.

Clicking such a combo could zoom the user into the rectangular section where he could jump between tree heads (no possibility to do it rn)

this isnt what you actually want tho is it? i just dont see how this is useful

I just thought that's a good starting point for implementing such.

[transmissions11]

aha! thank you so much for this, makes things muchhhh clearer (maybe we should require a sketch for all non trivial feature requests 🤔 )

this looks promising and doable

[UnloadingGnat]

hmmm interesting i saw the word workspaces and thought one thing (basically distinct tabs in flux that couldn't interact)

Could we still create something like that with organized tree navigation like @h0tw4t3r suggested. Flux -> multiple independent workspace -> multiple organized trees

Even something like this would be pretty cool https://reactflow.dev/docs/examples/interaction/contextual-zoom/ . Kind of like vscode's minimap