You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@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.
@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 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.
@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:
VS Code:
Terminal:
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
The text was updated successfully, but these errors were encountered: