search

daytonaio / daytona

The Open Source Dev Environment Manager.
https://daytona.io
Apache License 2.0
8.05k stars 770 forks source link

TUI selection UI's should print out the selection made #765

Open SvenDowideit opened 2 months ago

SvenDowideit commented 2 months ago

When I use the Charmbracelet TUI options, to make choices, they disappear (which is good), but in doing so, the fact that there was a choice, and what choice was made is gone, so when I'm trying to remember what happened by using my scrollback to figure out what did happen, I have no idea

It would be awesome if all TUI elements would be replaced by text that indicates that there was a choice made using the TUI, and what that choice was, and if that causes something to happen, to record that.

extra-awesome, would be if each TUI choice would record the commandline flag usage that would be needed when not using the TUI

one example is the "uninstall service" for daytona purge, another would be the IDE chosen for daytona ide

Tpuljak commented 1 month ago

When I use the Charmbracelet TUI options, to make choices, they disappear (which is good), but in doing so, the fact that there was a choice, and what choice was made is gone, so when I'm trying to remember what happened by using my scrollback to figure out what did happen, I have no idea

It would be awesome if all TUI elements would be replaced by text that indicates that there was a choice made using the TUI, and what that choice was, and if that causes something to happen, to record that.

@SvenDowideit can you elaborate a bit more on this? Maybe an example of how would it work. I'm not completely sure I understand what you mean by recording choices.

extra-awesome, would be if each TUI choice would record the commandline flag usage that would be needed when not using the TUI

one example is the "uninstall service" for daytona purge, another would be the IDE chosen for daytona ide

Do you mean that the command records an entry in you bash history with the appropriate flags?

SvenDowideit commented 1 month ago

In trying to find a good example, I've found alot of subtle ones, but I hope this one illustrates the idea:

in running daytona

the user gets several Charmbracelet screens. Lets say they choose daytona create, that then means they're TUI selecting

  1. Github organisation
  2. A repo in the chosen organistion
  3. A branch in that chosen repo

At each of those points, the previous selection is used to inform the next, but, once the TUI is finished, those choices are no longer visible to the user while the process is happening (until the very end - which can sometimes take quite a bit of time.

sven@x1carbon:~/src/daytona$ ./main
 WORKSPACE | ✓ Request submitted
 WORKSPACE | ✓ Creating workspace foswiki-distro (45438aac4cae)
 distro    | Creating project distro
 distro    | Pulling image...
 distro    | Pulling from daytonaio/workspace-project
 distro    | Digest: sha256:add38a473e9f16a4c077765872e4c0e6ee98862486337599e9e24b44be162235
 distro    | Status: Image is up to date for daytonaio/workspace-project:latest
 distro    | Image pulled successfully
 distro    | UIDs and GIDs are the same (1000:1000).
 distro    | Cloning into '/workdir/45438aac4cae-distro'...
 distro    | Pulling image...
 distro    | Pulling from daytonaio/workspace-project
 distro    | Digest: sha256:add38a473e9f16a4c077765872e4c0e6ee98862486337599e9e24b44be162235
 distro    | Status: Image is up to date for daytonaio/workspace-project:latest
 distro    | Image pulled successfully
 WORKSPACE | ✓ Workspace creation complete. Pending start...
 WORKSPACE | ✓ Starting workspace
 distro    | Project distro created
 distro    | Starting project distro
 distro    | Downloading Daytona binary from https://api-1f3b7fa4-b4d9-4584-9d13-3eedd52885e5.try-eu.daytona.app/binary/v0.0.0-dev/daytona-linux-amd64
 distro    | Project distro started
 WORKSPACE | ✓ Workspace foswiki-distro started
 distro    | Installing server to /usr/local/bin
 distro    | Starting Daytona Agent
 distro    | Repository already exists. Skipping clone...
 distro    | No post create commands to run
 distro    | Running post start commands...
 distro    | Starting ssh server on port 2222...
 distro    | Failed to connect to server: Get "http://server/health": context deadline exceeded (Client.Timeout exceeded while awaiting headers). Reconnecting...
 distro    | Reconnected to server

   Workspace       foswiki-distro                                                                 

   ID              45438aac4cae                                                                   

   Editor          GoLand                                                                         

   State           RUNNING                                                                        

   Branch          master                                                                         

   Repository      github.com/foswiki/distro                                                      

 Run 'daytona code' when you're ready to start developing

That seems fine, except, if any part of the above process fails, the command errors out, and doesn't print the summary. And probably just as difficult, the summary isn't directly reminding the user of which choices they actively made, or when they made them.

For this reason, I'm thinking it would be excellent, if the post TUI output looked more like:

sven@x1carbon:~/src/daytona$ ./main
TUI| user selected `daytona create`
TUI| user selected `GitHub provider` with (I suspect each GithHub token should have a nickname, so someone with more than one org would know which?)
TUI| user selected GitHub organisation: `foswiki`
TUI| user selected foswiki org repo `distro`
TUI| user selected distro repo branch `master`
TUI| user selected to name new Workspace: `foswiki-distro`
 WORKSPACE | ✓ Request submitted
 WORKSPACE | ✓ Creating workspace foswiki-distro (45438aac4cae)
 distro    | Creating project distro
 distro    | Pulling image...
 distro    | Pulling from daytonaio/workspace-project
 distro    | Digest: sha256:add38a473e9f16a4c077765872e4c0e6ee98862486337599e9e24b44be162235
 distro    | Status: Image is up to date for daytonaio/workspace-project:latest
 distro    | Image pulled successfully
 distro    | UIDs and GIDs are the same (1000:1000).
 distro    | Cloning into '/workdir/45438aac4cae-distro'...
 distro    | Pulling image...
 distro    | Pulling from daytonaio/workspace-project
 distro    | Digest: sha256:add38a473e9f16a4c077765872e4c0e6ee98862486337599e9e24b44be162235
 distro    | Status: Image is up to date for daytonaio/workspace-project:latest
 distro    | Image pulled successfully
 WORKSPACE | ✓ Workspace creation complete. Pending start...
 WORKSPACE | ✓ Starting workspace
 distro    | Project distro created
 distro    | Starting project distro
 distro    | Downloading Daytona binary from https://api-1f3b7fa4-b4d9-4584-9d13-3eedd52885e5.try-eu.daytona.app/binary/v0.0.0-dev/daytona-linux-amd64
 distro    | Project distro started
 WORKSPACE | ✓ Workspace foswiki-distro started
 distro    | Installing server to /usr/local/bin
 distro    | Starting Daytona Agent
 distro    | Repository already exists. Skipping clone...
 distro    | No post create commands to run
 distro    | Running post start commands...
 distro    | Starting ssh server on port 2222...
 distro    | Failed to connect to server: Get "http://server/health": context deadline exceeded (Client.Timeout exceeded while awaiting headers). Reconnecting...
 distro    | Reconnected to server

   Workspace       foswiki-distro                                                                 

   ID              45438aac4cae                                                                   

   Editor          GoLand                                                                         

   State           RUNNING                                                                        

   Branch          master                                                                         

   Repository      github.com/foswiki/distro                                                      

 Run 'daytona code' when you're ready to start developing

icing on the cake would be to teach the user what the non TUI cli would be, but that might be excessive :)

Tpuljak commented 1 month ago

That seems fine, except, if any part of the above process fails, the command errors out, and doesn't print the summary. And probably just as difficult, the summary isn't directly reminding the user of which choices they actively made, or when they made them.

Ah, I understand now.

We could print out a summary of some sort before we start streaming the logs. cc @idagelic ?

Regarding informing the user about general TUI selection, that might be more of a nuisance than help in some cases. The workspace creation TUI is the only one that would suffer with the issue you outlined since it's the only view with such an intricate form system.

SvenDowideit commented 1 month ago

I've had the same issue elsewhere - where I started a process with a single TUI, then walked away to do something else, and wondered what I selected when I came back.

its less about complexity, and more about reminding the user, for whom this might be one very small part of what they're working on :)

idagelic commented 1 month ago

@SvenDowideit Regarding the "summary" before reading logs - this already exists if you try running daytona create -> select a repo and go into the f10 advanced config view. Upon completion of the configuration there is a summary displayed.

image

The summary is not displayed if the user didn't try to configure the project further. The reason for this is that we assume the user is aware of the git provider + namespace + repo + branch they selected. After all, this is in essence just a single entry for which we added some UI helpers. After the request is submitted, the repo name is visible right away in the first couple lines. Adding a summary view for users that didn't want any customizations would seem like bloat.

image

Looking back, the summary view could use some formatting improvements as well as a "Branch" property under the project. Is this something you were looking for? Do you think any other views require a similar summary?

idagelic commented 1 month ago

@SvenDowideit is the summary from the screenshot the thing you were looking for? Let me know if you'd like anything specific to be done as part of this issue

SvenDowideit commented 1 month ago

Yeah, I suspect that the summary would help - the problem is that "we assume the user is aware of the git provider + namespace + repo + branch they selected" is very dependent on the user not being distracted, or trying to work out a few hours later why it failed (consider for example, going through the UI options, ad then going to lunch - only to come back a while later, and trying to work out what you'd chosen.

I suspect it's better to have a record of what was selected in the UI, and not leaving the user to figure out how to find out.

idagelic commented 1 month ago

@SvenDowideit Got it. Created a separate issue #855 to take care of that. Thanks!

Keeping this open for now if you have any similar feature requests regarding the TUI ux?