Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove "Move apps if present" setting in editor #76

Open
plante-msft opened this issue Aug 5, 2024 · 2 comments
Open

Remove "Move apps if present" setting in editor #76

plante-msft opened this issue Aug 5, 2024 · 2 comments
Assignees
Labels
editor P0 Highest priority item, ship blocking solved

Comments

@plante-msft
Copy link
Collaborator

@donlaci you might hate me for this, but after looking into it more and testing a bunch of different apps, I think we should remove this setting altogether. Reason being that most apps that have the ability to launch new instances or re-use existing windows have some CLI argument(s) that allows the user to explicitly set this behaviour. This is easier for both users and our team as opposed to having a setting with caveats that we need to spell out.

Some examples below:

Edge:

  • If CLI arg for website is present, Edge will open it in an existing window if present, or launch new if not.
  • BUT user can force new window with --new-window CLI argument

VS Code:

  • VS behaves similarly to Edge, but window behaviour can be controlled by --new-window and --reuse-window commands if user desires

Terminal:

  • Windows Terminal can be configured to "launch as new tab" in CLI arg, which will use existing window if present, but launch new window if not

I will add a section that explains "How to move existing windows" in the docs to specify users to use command line args for this.

Sorry for going back and forth on this!

cc @hamza-usmani

@plante-msft plante-msft added editor P0 Highest priority item, ship blocking labels Aug 5, 2024
@donlaci
Copy link
Collaborator

donlaci commented Aug 6, 2024

@plante-msft No worries, if it is the best solution, we will implement it that way.
My typical scenario is while testing the feature that many apps (10+) are already open when launching an AppLayout. The launcher then finishes in a blick of the eye.
Most probably the typical scenario for the future users is different, but I can imagine also scenarios when the user clicks the shortcut accidentaly or he/she will want just a reordering of his/her apps - I use it for switching between "work layout" amd "meeting layout" having quite the same apps. So avoiding re-opening apps is my preference but I accept your reasoning.
I would suggest to remove the UI checkbox and temporarily keep the current implementation with both modes where only one will be effective. We can clean up later the "move" code parts if it won't be used.

@donlaci donlaci self-assigned this Aug 6, 2024
@donlaci donlaci added the solved label Aug 6, 2024
@plante-msft
Copy link
Collaborator Author

@donlaci yes, we should keep the existing implementation here where we naively call the .exe with the CLI arguments. If the app's default behaviour is to move the window and apply args, then great. If it's default is to spawn a new window, then that is fine as well.

From our side, we will direct users to first govern this behaviour (if they want) with CLI args when available.

TL;DR we remove the UI checkbox completely and do not modify existing behaviour.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
editor P0 Highest priority item, ship blocking solved
Projects
None yet
Development

No branches or pull requests

2 participants