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

Feature Request: Start teminal when user log-in #2189

Closed
leoniDEV opened this issue Aug 1, 2019 · 5 comments · Fixed by #4908
Closed

Feature Request: Start teminal when user log-in #2189

leoniDEV opened this issue Aug 1, 2019 · 5 comments · Fixed by #4908
Labels
Area-Settings Issues related to settings and customizability, for console or terminal Help Wanted We encourage anyone to jump in on these. Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.

Comments

@leoniDEV
Copy link

leoniDEV commented Aug 1, 2019

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 manifest

@leoniDEV leoniDEV added the Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. label Aug 1, 2019
@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Aug 1, 2019
@leoniDEV leoniDEV changed the title Feature Request: Start teminal when system startup Feature Request: Start teminal when user log-in Aug 1, 2019
@zadjii-msft zadjii-msft added Area-Settings Issues related to settings and customizability, for console or terminal Product-Terminal The new Windows Terminal. labels Aug 1, 2019
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Aug 1, 2019
@zadjii-msft zadjii-msft added this to the Terminal Backlog milestone Aug 1, 2019
@zadjii-msft zadjii-msft added this to Spec Needed ❓ in Specification Tracker via automation Aug 1, 2019
@zadjii-msft zadjii-msft added the Help Wanted We encourage anyone to jump in on these. label Aug 1, 2019
@miniksa
Copy link
Member

miniksa commented Aug 1, 2019

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
https://docs.microsoft.com/en-us/uwp/api/Windows.ApplicationModel.StartupTask.RequestEnableAsync

@miniksa miniksa removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Aug 1, 2019
@jelster
Copy link
Contributor

jelster commented Mar 9, 2020

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 Notes

Scenario: 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 login

Test/Use Cases

  • AppX manifest should define the startupTask extension pointing at the main application entry point. . [note: I am still not familiar enough with the project structure to say exactly which manifest will need this] Here are some candidates:
    - CascadiaPackage
    - WindowsTerminalUniversal

  • When the default profile is generated, the StartOnUserLogin setting should be created with an initial value of false

    • Modify GlobalAppSettings to add StartOnUserLogin global app setting.
    • Include implementations for To/FromJson, ApplyToSettings, etc
  • Users should be allowed to specify additional command-line args to be passed to terminal launch on startup. A new global setting, StartupCommandLineArgs (note: need a better name?) is used to store a flat string of arguments that are passed straight-through

  • When the application (re)loads settings, and the StartOnUserLogin setting is populated with a true value, the StartupTask.RequestEnableAsync process is invoked

    • Incorporate into AppLogic methods to request enable/disabling of startup task via StartupTask.GetAsync...
  • When the application settings are (re)loaded, and the StartOnUserLogin setting is false, the StartupTask.Disable process is invoked

    • AppLogic::OnLoaded add conditional logic to invoke the enable on startup request process implemented earlier via the startupTask.RequestEnableAsync helper
    • AppLogic::ReloadSettings Add call to startup task logic [note: not sure if this is correct location. Potentially RegisterSettingsChange could be leveraged]
  • When application settings are loaded, if an invalid (e.g., "truthy", "12/23/2020") or unreadable value is encountered, an exception should not be thrown, and the StartOnUserLogin setting should have a materialized value of false

Outstanding Questions

  • Does it make a difference if StartupTask.Disable is called on an already-disabled task? If not, no need to check previous setting's value

  • How should errors in enabling/disabling of the task be handled? Since the application will only be initiating the request process, can we expect the OS to handle error conditions(e.g., user cancels out/loses power/restarts/etc without selecting anything), either partially or fully?

  • With the startup task running on user login, are there any assumptions made by the application regarding availability of certain UI services that may not hold up?

HTH!

@jelster
Copy link
Contributor

jelster commented Mar 10, 2020

@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?

@zadjii-msft
Copy link
Member

Honestly, you could probably edit-in-place here if you want.

@ghost ghost added the In-PR This issue has a related PR label Mar 13, 2020
@ghost ghost closed this as completed in #4908 Jun 1, 2020
@ghost ghost removed the In-PR This issue has a related PR label Jun 1, 2020
ghost pushed a commit that referenced this issue Jun 1, 2020
<!-- 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
@ghost ghost added the Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. label Jun 1, 2020
@ghost
Copy link

ghost commented Jun 18, 2020

🎉This issue was addressed in #4908, which has now been successfully released as Windows Terminal Preview v1.1.1671.0.:tada:

Handy links:

@zadjii-msft zadjii-msft moved this from Spec Needed ❓ to Spec Accepted! 🎉 in Specification Tracker Aug 12, 2020
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Settings Issues related to settings and customizability, for console or terminal Help Wanted We encourage anyone to jump in on these. Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Projects
Specification Tracker
  
Spec Accepted! 🎉
Development

Successfully merging a pull request may close this issue.

4 participants