[workspace]: Pass WorkspaceInput argument into reloadWindow/openNewWindow methods

[kittaakos]

What it does

This PR changes the workspace service API and passes the WorkspaceInput argument down to the openNewWindow and reloadWindow methods.

I would like to extend the functionality of the workspace service without unnecessarily copy-pasting logic that is irrelevant. I need the original WorkspaceInput to customize the app's behavior after opening a new or reloading the current window. for example, I want to reload a window and run a series of custom commands or open/reveal widgets.

How to test

I added a sample in a separate commit to demo the desired behavior.

• Use the Reload Window and Open New Terminal command to reload the workspace and open a new terminal,
• Use the Open New Workspace and Reveal Explorer command to open a new workspace and activate the Explorer view.
• The examples are made-up samples and have nothing to do with the requested API changes. With the new APIs, the workspace customization can be simplified into a couple of lines of code. Please see the sample example.

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines

[kittaakos]

// CC @AlbyIanna

[colin-grant-work]

I'm perfectly happy with the changes to the WorkspacesService: I don't see any reason that information shouldn't be available to those methods.

I have some doubts about the sample API contribution, though. My impression of the new feature is that it's basically intended to be a CLI of sorts, but for the browser: a way to pass arguments that can be interpreted as the downstream application wishes. Until now, we've had one 'positional' argument, the path to the workspace, but this PR envisions (reasonably) that we might want more. If we want to go this route, might it make sense to build some infrastructure around it - the code that clears the additional arguments from the URL makes me a little nervous.

Another question is whether this is the best way to accomplish the objective. The use-case seems to be cases where one window is opened from another window, since anything else could be handled by the actual CLI. If that's the use case, then rather than passing arguments in the URL, inter-window messaging could be used, since the parent window has access to the child window and could send it a message encoding the details of its 'startup task' when the window was ready to handle it. That would lose some of the flexibility of the URL-based approach - it could never be used for the first window - but it would avoid messing with the URL at all and so confusing the existing workspace setup.

[colin-grant-work]

Move everything below here into its own file.

[kittaakos]

I'm perfectly happy with the changes to the WorkspacesService: I don't see any reason that information shouldn't be available to those methods.

Thank you so much for the self-assignment.

I have some doubts about the sample API contribution, though.

I wanted to drop the example before the merge. Let me know if the API changes are OK, and I will remove the last commit.

The sole purpose of the sample was to show that custom behavior can be achieved by overriding the openNewWindow and reloadWindow with the proposed API changes. In the Arduino IDE, we would like to make the Theia version updates easy and avoid unnecessary customizations, such as doOpen and openWindow.

My impression of the new feature is that it's basically intended to be a CLI of sorts, but for the browser: a way to pass arguments that can be interpreted as the downstream application wishes.

I appreciate that you have taken the time to think this further. It is precisely the bahevior we want, but it's not yet clear how to support it properly in the long run. URLs have a limited length, so URL manipulation is not the ultimate solution.

Until now, we've had one 'positional' argument, the path to the workspace, but this PR envisions (reasonably) that we might want more. If we want to go this route, might it make sense to build some infrastructure around it - the code that clears the additional arguments from the URL makes me a little nervous.

Absolutely. When we have a distilled approach, I am happy to open a GH discussion or PR and decide on the details with the core committers. Currently, IDE2's top priority is to run in electron. Theia requires a browser and electron solution.

Another question is whether this is the best way to accomplish the objective. The use-case seems to be cases where one window is opened from another window, since anything else could be handled by the actual CLI. If that's the use case, then rather than passing arguments in the URL, inter-window messaging could be used, since the parent window has access to the child window and could send it a message encoding the details of its 'startup task' when the window was ready to handle it. That would lose some of the flexibility of the URL-based approach - it could never be used for the first window - but it would avoid messing with the URL at all and so confusing the existing workspace setup.

Great idea. I also thought about it but decided to use the URL workaround for now. Here is why:

• Window A opens B and wants to send an "initial config" via IPC to window B,
• While B is loading (did-finish-load not fired yet), window A closes,
• B might never receive the message.

Please correct me if I am conceptually wrong or if you have a better idea. Thank you!

[colin-grant-work]

I wanted to drop the example before the merge. Let me know if the API changes are OK, and I will remove the last commit.

Sounds good - if you drop that commit, I'll happily approve 👍 .

[colin-grant-work]

LGTM, and sure to be useful to some adopters. 👍

[kittaakos]

@colin-grant-work, could you please proceed with the merge if the PR looks good? Thank you!