-
Notifications
You must be signed in to change notification settings - Fork 8.4k
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
Feature Request: Start teminal when user log-in #2189
Comments
If someone wants to add something like this following the MSDN documentation on adding a startup task, we're fine with it. https://docs.microsoft.com/en-us/uwp/api/Windows.ApplicationModel.StartupTask |
I want to help out with this, so I've been assessing the work involved in doing it. Though this isn't quite in my wheelhouse, I figured that laying these thoughts out might help move this particular feature along a bit even if I'm not able to actually complete everything on my own. Feedback on the below worklist is appreciated as I'm sure there's a lot I've missed or gotten wrong in this first draft! Implementation NotesScenario: Users should be able to enable a global setting that results in the enable/disable of the startup task that launches Terminal on a user loginTest/Use Cases
Outstanding Questions
HTH! |
@miniksa - would you prefer I create a new issue following the same format as this to track these specs, or continue to edit in-place with refinements? |
Honestly, you could probably edit-in-place here if you want. |
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request This PR adds a new boolean global setting, startOnUserLogin, along with associated AppLogic to request enabling or disabling of the StartupTask. Added UAP5 extensions to AppX manifests. <!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> ## References #2189 <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Closes #2189 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [x] Tests added/passed * [x] Requires documentation to be updated * [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #2189 <!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments Please note, I'm a non-practicing C++ developer, there are a number of things I wasn't sure how to handle in the appropriate fashion, mostly around error handling and what probably looks like an incredibly naive (and messy) way to implement the async co_await behavior. Error handling-wise, I found (don't ask me how!) that if you somehow mismatch the startup task's ID between the manifest and the call to `StartupTask::GetAsync(hstring taskId)`, you'll get a very opaque WinRT exception that boils down to a generic invalid argument message. This isn't likely to happen in the wild, but worth mentioning... I had enough trouble getting myself familiarized with the project, environment, and C++/WinRT in general didn't want to try to tackle adding tests for this quite yet since (as I mentioned) I don't really know what I'm doing. I'm happy to give it a try with perhaps a bit of assistance in getting started 😃 Further work in this area of the application outside of this immediate PR might need to include adding an additional setting to contain launch args that the startup task can pass to the app so that users can specify a non-default profile to launch on start, window position (e.g., #653). <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed ✔️ Default settings: Given the user does not have the `startOnUserLogin` setting in their profile.json, When the default settings are opened (via alt+click on Settings), Then the global settings should contain the `"startOnUserLogin": false` token ✔️ Applying setting on application launch Given the `startOnUserLogin` is `true` and the `Windows Terminal` startup task is `disabled` and the application is not running When the application is launched Then the `Windows Terminal` entry in the user's Startup list should be `enabled` ✔️ Applying setting on settings change Given the `startOnUserLogin` is `true` and the `Windows Terminal` startup task is `enabled` and the application is running When the `startOnUserLogin` setting is changed to `false` and the settings file is saved to disk Then the `Windows Terminal` startup task entry should be `disabled` ✔️ Setting is ignored when user has manually disabled startup Given the `startOnUserLogin` is `true` and the application is not running and the `Windows Terminal` startup task has been set to `disabled` via user action When the application is launched Then the startup task should remain disabled and the application should not throw an exception #### note: Task Manager does not seem to re-scan startup task states after launch; the Settings -> Apps -> Startup page also requires closing or moving away to refresh the status of entries
🎉This issue was addressed in #4908, which has now been successfully released as Handy links: |
Description of the new feature/enhancement
Over time I written many Powershell scripts and modules to manage many stuff (either for personal and for work) I use some modules for manage my dev environment or my home router, or move, rename, delete personal fotos, ect.
So I'm used to have a Powershell session start when I log-in.
Now I want to move to Windows Terminal and so I would like to have it to start when I log-in
Proposed technical implementation details (optional)
The UWP SDK expose a way to configure a packaged app to start when a user log-in by adding the
windows.startupTask
extention to the manifestThe text was updated successfully, but these errors were encountered: