Feature Request: Allow users to select code editor and terminal app

[matt-west]

trafficstars

What

Studio currently supports quick actions for VS Code, PhpStorm, and the Terminal app. Users should be able to choose any code editor/terminal they have installed so the quick actions match their preference.

Why

• People are more likely to use these quick actions if they can customise them to open their favourite tools.
• Studio currently prioritises VS Code over PhpStorm for users that have both installed. This may not match the user's preference.

How

Here’s how GitHub Desktop handles this:

[faisalahammad]

+1

[bacoords]

+1

[matt-west]

@michalczaplinski I did a quick pass of the app settings screen to facilitate adding the options to select a code editor and shell.

I think we’ll need to implement tabs inside the modal as there’s too much in here now to fit in one page comfortably. It adds some complexity to this task, but I foresee us adding more options to app settings in the future so I think it's worth the extra time investment.

We can place these new fields in a Preferences tab alongside the Language selector:

Usage metrics have moved to a dedicated tab. This would only be visible to users that have connected a WordPress.com account as these features are unavailable otherwise.

The default tab would be Accounts, with options to connect a WordPress.com or Pressable account. (@crisbusquets I’ve tried to integrate your work on Pressable Sync here.)

Full designs can be found here: RToz6tIuQ7nlZrikBte4GU-fi-2658_81168

Let me know if you have any thoughts or feedback on these designs.

[crisbusquets]

The default tab would be Accounts, with options to connect a WordPress.com or Pressable account. (@crisbusquets I’ve tried to integrate your work on Pressable Sync here.)

Ah, thank you for this! That would simplify everything we were discussing here p58i-k0d-p2 (cc @fredrikekelund @draganescu ).

[michalczaplinski]

Thanks @matt-west for moving so quickly with the designs! 😃

A few thoughts:

1. Do you think that we need the "Cancel" and "Save" buttons in the Preferences tab? Currently, the language just switches immediately when selected in the dropdown. We could do the same for the Editor and Terminal.

2. Any thoughts on how the selector for the IDE/Terminal should work? In the current design, it looks like it could be a dropdown with a list of editors/terminals. However, it might be better UX to allow the user to select an application with which to open by default. This way, we could avoid hardcoding a list of IDEs/terminals. On the other hand, I'm not sure how this would work on Windows/Linux.

3. Minor detail: Should the tabs have a black underline instead of the blue one? The tabs on the main screen do, so might make sense to follow those components for consistency.

[michalczaplinski]

Any thoughts on how the selector for the IDE/Terminal should work?

Regarding this, WP Local has a hardcoded list of Terminal applications but only the ones that are available on your machine show up as selectable. This could be another option for the UX.

https://github.com/user-attachments/assets/53910194-2ae8-4f41-b5a4-663c8d86e1a9

[fredrikekelund]

Any thoughts on how the selector for the IDE/Terminal should work? In the current design, it looks like it could be a dropdown with a list of editors/terminals. However, it might be better UX to allow the user to select an application with which to open by default. This way, we could avoid hardcoding a list of IDEs/terminals.

I don't entirely understand the question… Is your point that we should only display installed applications in the dropdown?

GitHub Desktop has some pretty solid logic for this. It's worth looking at their implementation. They have a predefined list of applications (terminals and editors) with assertions to determine if said app is installed. If it is, it's presented as an option in the settings dropdown.

Copying their implementation would be a great start, IMO.

[wojtekn]

Any thoughts on how the selector for the IDE/Terminal should work? In the current design, it looks like it could be a dropdown with a list of editors/terminals. However, it might be better UX to allow the user to select an application with which to open by default. This way, we could avoid hardcoding a list of IDEs/terminals. On the other hand, I'm not sure how this would work on Windows/Linux.

@michalczaplinski I think we won't be able to allow users to choose any app as we have an app-specific code for each supported app. It could be a list of the apps Studio supports, and probably those not available on the user's machine should be disabled.

[michalczaplinski]

@wojtekn Got it, thanks!

Is your point that we should only display installed applications in the dropdown?

@fredrikekelund Nope, I was asking in general 🙂. My suggestion was that we could use a native modal where a user can select an Application with which to "open". E.g. on MacOS it looks something like this (this is for opening a PDF file, but you can imagine it working for opening a directory in the terminal.

But I guess it's a moot point since Wojtek mentioned that we cannot allow this anyways.

Thanks for the suggestion about Github Desktop - I'll take a look at their implementation!

[matt-west]

Do you think that we need the "Cancel" and "Save" buttons in the Preferences tab? Currently, the language just switches immediately when selected in the dropdown. We could do the same for the Editor and Terminal.

I think the explicit Save and Cancel buttons are necessary. We’re moving away from auto-saving fields (with the exception of toggles) so makes sense to be consistent with our other settings screens.

Any thoughts on how the selector for the IDE/Terminal should work? In the current design, it looks like it could be a dropdown with a list of editors/terminals. However, it might be better UX to allow the user to select an application with which to open by default. This way, we could avoid hardcoding a list of IDEs/terminals. On the other hand, I'm not sure how this would work on Windows/Linux.

As already suggested above, let’s make this a simple dropdown. We can support the most common editors and only display options for those installed. In the future, we might include the ability to configure a custom editor like GH desktop does, but I think it’s beyond the scope of this initial project.

Minor detail: Should the tabs have a black underline instead of the blue one? The tabs on the main screen do, so might make sense to follow those components for consistency.

Let’s keep the black underline for consistency. The Core component uses blue. We might want to adopt that in the future, but it should be done as a wider effort to align with Core component styling.

[michalczaplinski]

I think the explicit Save and Cancel buttons are necessary. We’re moving away from auto-saving fields (with the exception of toggles) so makes sense to be consistent with our other settings screens.

Got it! I will add the "Accounts", "Preferences" & "Usage" tabs as the first step and then add the "Save" and "Cancel" buttons for the "Preferences".

As already suggested above, let’s make this a simple dropdown. We can support the most common editors and only display options for those installed.

Agreed, makes sense!

[michalczaplinski]

@matt-west I've thought about this a bit:

only display options for those installed.

I believe it would be clearer to display a fixed list of supported editors—such as VSCode, Cursor, PHPStorm, and any other editors we choose to support. My reasoning:

• If a user only has VSCode installed, the dropdown would show just one option, which might feel redundant or unclear:

  https://github.com/user-attachments/assets/8ec6b8e0-efb9-4fca-af55-936c0bf05565

• Worse, if no supported editors are installed, the dropdown would appear empty, creating potential confusion.

A fixed list clearly communicates which editors are supported, even though a user might select an editor they haven't installed. Users typically know which applications they have, so this shouldn't cause significant issues.

The same logic applies to selecting a default terminal.

[matt-west]

Let’s put the editors that are not installed in an optgroup to separate them in the list and disable those options. Otherwise it would be a bit confusing to have options for apps that aren’t installed.

If no text editors are installed we could disable the field and display a note recommending VS Code.

[michalczaplinski]

@matt-west Excellent, that's a nice solution 👍 .

[michalczaplinski]

👋 @matt-west

I've made some progress on the initial steps for this:

• https://github.com/Automattic/studio/pull/1075
• https://github.com/Automattic/studio/pull/1164

However, I notice an issue: If I make the Modal fixed height (like in the designs) there is quite a bit of whitespace, especially in the Account tab. That's because we only allow users to connect a single WordPress.com account:

https://github.com/user-attachments/assets/56d063c5-aa5b-42cd-b6fc-ef0aeba96559

On the other hand, if I make the Modal flexible height, there's a pretty jarring jump when switching tabs:

https://github.com/user-attachments/assets/9ccd2339-07b4-427a-bb23-13e05da5f53a

Two solutions come to mind:

1. Make the User Settings modal fill the full page. Either using the size="full" prop or the isFullPage={true} prop of the Modal component

   https://github.com/user-attachments/assets/92fa4291-f575-4ea2-a8a7-7238f6e654db

2. Add an animation to the Modal which animates the height of the modal whenever a tab is switched.

What are your thoughts?

[matt-west]

Thanks for the ping @michalczaplinski, and for exploring some possible solutions. I agree that varying the height of the modal as you switch tabs is jarring.

The full-height option suffers the same issue of having too much empty space. That will be exaggerated at larger window sizes.

Can we use the height of the tallest tab content? (In this case Preferences)

The height in the Figma design was based on that, but it needs tweaking here as we don’t have all the options yet. We’ll still have additional whitespace on some tabs, but I think it's a good middle-ground.

[michalczaplinski]

Can we use the height of the tallest tab content? (In this case Preferences)

We can do that. 👍 I can hardcode it for the time being to 350px and once we have more options, it would have to be adjusted.

[gcsecsey]

This feature is now shipped with the Studio v1.5.1 release to all users. pfHvTO-ws-p2