Feature Request: Option to only allow one instance #2227
Assignees
Labels
Area-User Interface
Issues pertaining to the user interface of the Console or Terminal
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.
Milestone
Comments
Johannestegner
added
the
Issue-Feature
ghost
added
Needs-Triage
zadjii-msft
added
Area-User Interface
DHowett-MSFT
removed
the
Needs-Triage
|
Triage: backlogged, needs a spec, but MIGHT be handled by a comprehensive look at #2080. |
80 tasks
3 tasks
5 tasks
7 tasks
ghost
pushed a commit
that referenced
this issue
Jan 19, 2021
This PR adds a sample monarch/peasant application. This is a type of application where a single "Monarch" can coordinate the actions of multiple other "Peasant" processes, as described by the specs in #7240 and #8135. This project is intended to be a standalone sample of how the architecture would work, without involving the entirety of the Windows Terminal build. Eventually, this architecture will be incorporated into `wt.exe` itself, to enable scenarios like: * Run `wt` in the current window (#4472) * Single Instance Mode (#2227) For an example of this sample running, see the below GIF:  This sample operates largely by printing to the console, to help the reader understand how it's working through its logic. I'm doing this mostly so we can have a _committed_ sample of this type of application, kinda like how VtPipeTerm is a sample ConPTY application. It's a lot easier to understand (& build on) when there aren't any window shenanigans, settings loading, Island instantiation, or anything else that the whole of `WindowsTerminal.exe` needs * [x] I work here * [x] This is sample code, so I'm not shipping tests for it. * [x] Go see the doc over in #8135
mpela81
pushed a commit
to mpela81/terminal
that referenced
this issue
Jan 28, 2021
This PR adds a sample monarch/peasant application. This is a type of application where a single "Monarch" can coordinate the actions of multiple other "Peasant" processes, as described by the specs in microsoft#7240 and microsoft#8135. This project is intended to be a standalone sample of how the architecture would work, without involving the entirety of the Windows Terminal build. Eventually, this architecture will be incorporated into `wt.exe` itself, to enable scenarios like: * Run `wt` in the current window (microsoft#4472) * Single Instance Mode (microsoft#2227) For an example of this sample running, see the below GIF:  This sample operates largely by printing to the console, to help the reader understand how it's working through its logic. I'm doing this mostly so we can have a _committed_ sample of this type of application, kinda like how VtPipeTerm is a sample ConPTY application. It's a lot easier to understand (& build on) when there aren't any window shenanigans, settings loading, Island instantiation, or anything else that the whole of `WindowsTerminal.exe` needs * [x] I work here * [x] This is sample code, so I'm not shipping tests for it. * [x] Go see the doc over in microsoft#8135
zadjii-msft
added a commit
that referenced
this issue
Feb 5, 2021
### ⇒ [doc link](https://github.com/microsoft/terminal/blob/dev/migrie/s/5000/doc/specs/%235000%20-%20Process%20Model%202.0/%235000%20-%20Process%20Model%202.0.md) ⇐ ## Summary of the Pull Request This spec is _exceptionally long_, and is currently a work in progress. There are a few more things I'd like to have experimentally verified (though, I'm fairly certain they _will_ work, with the right combination of flags and such). Additionally, a few sections have remaining TODOs before the spec is finished. However, this spec is already fairly long, and I want to give people as much time to get their eyes on it as possible. ### Abstract > > The Windows Terminal currently exists as a single process per window, with one > connection per terminal pane (which could be an additional conpty process and > associated client processes). This model has proven effective for the simple > windowing we've done so far. However, in order to support scenarios like > dragging tabs into other windows, or having one top-level window with different > elevation levels within it, this single process model will not be sufficient. > > This spec outlines changes to the Terminal process model in order to enable the > following scenarios: > > * Tab Tearoff/ Reattach ([#1256]) > * Run `wt` in the current window ([#4472]) > * Single Instance Mode ([#2227]) > * Quake Mode ([#653]) > * Mixed Elevation ([#1032] & [#632]) ## PR Checklist * [x] Specs: #5000 * [x] References: #1256, #4472, #2227, #653, #1032, #632, #492 * [x] I work here ## Detailed Description of the Pull Request / Additional comments _\*<sup>\*</sup><sub>\*</sub> read the spec <sub>\*</sub><sup>\*</sup>\*_
zadjii-msft
added a commit
that referenced
this issue
Feb 5, 2021
### ⇒ [doc link](https://github.com/microsoft/terminal/blob/dev/migrie/s/4472-window-management/doc/specs/%235000%20-%20Process%20Model%202.0/%234472%20-%20Windows%20Terminal%20Session%20Management.md) ⇐ ## Summary of the Pull Request This is a more detailed spec for two parts of the "Process Model 2.0" work that's being tracked in #5000. In particular, this spec focuses on the management of Windows Terminal windows, including opening new tabs in existing windows. Largely, the reader is expected to have already read the spec in progress in #7240, and already be familiar with the concept of "Monarch" and "Peasant" windows as introduced by that spec. For that reason, ⚠ **THIS PR IS TARGETING THE BRANCH FOR #7240** ⚠. ### Abstract > This document is intended to serve as an addition to the [Process Model 2.0 > Spec]. That document provides a big-picture overview of changes to the entirety > of the Windows Terminal process architecture, including both the split of > window/content processes, as well as the introduction of monarch/peasant > processes. The focus of that document was to identify solutions to a set of > scenarios that were closely intertwined, and establish these solutions would > work together, without preventing any one scenario from working. What that > document did not do was prescribe specific solutions to the given scenarios. > > This document offers a deeper dive on a subset of the issues in [#5000], to > describe specifics for managing multiple windows with the Windows Terminal. This > includes features such as: > > * Run `wt` in the current window ([#4472]) > * Single Instance Mode ([#2227]) ## PR Checklist * [x] Specs: #4472, Specs #2227 * [x] References: #5000, #4472, #2227, #7240 * [x] I work here ## Detailed Description of the Pull Request / Additional comments _\*<sup>\*</sup><sub>\*</sub> read the spec <sub>\*</sub><sup>\*</sup>\*_ ### Why are these two separate documents? I felt that the spec that is currently in review in #7240 and this doc should remain separate, yet closely related documents. #7240 is more about showing how this large set of problems discussed in #5000 can all be solved technically, and how those solutions can be used together. It establishes that none of the proposed solutions for components of #5000 will preclude the possibility of other components being solved. What it does _not_ do however is drill too deeply on the user experience that will be built on top of those architectural changes. This doc on the other hand focuses more closely on a pair of scenarios, and establishes how those scenarios will work technically, and how they'll be exposed to the user. ### TODO: * [x] A thought - How will we handle arguments like `--fullscreen`, `--initialSize r,c`? They only apply when creating a new window, right? * [x] When a `wt -s 1 split-pane` command is executed, we'll need to make sure to not _also_ create a new tab
ghost
added
Resolution-Fix-Committed
ghost
pushed a commit
that referenced
this issue
Feb 19, 2021
Adds support for the `windowingBehavior` global setting. This setting controls how mutiple instances of `wt` behave in the absence of the `-w` parameter. This setting has three values: * `"useNew"`: (default) Multiple `wt` invocations (without the `-w` param) always create new windows. * `"useAnyExisting"`: When starting a new `wt`, we'll instead default to any existing windows. `wt -w -1` will still create new windows. * `"useExisting"`: Similar to `useAnyExisting`, but limits to windows on the current desktop. The IVirtualDesktopManager interface is _very_ limited. Hence why we have to track the HWNDs manually, and ask if they're on the current desktop. ## Validation Steps Performed I've been playing with it for a week now. References #5000 References projects/5 References #8898 Spec'd in #8135 Closes #2227 Closes https://github.com/microsoft/terminal/projects/5#card-51431448 Closes https://github.com/microsoft/terminal/projects/5#card-51431433
|
🎉This issue was addressed in #9118, which has now been successfully released as Handy links: |
ghost
pushed a commit
that referenced
this issue
Apr 21, 2021
### ⇒ [doc link](https://github.com/microsoft/terminal/blob/dev/migrie/s/653-quake-mode/doc/specs/%23653%20-%20Quake%20Mode/%23653%20-%20Quake%20Mode.md) ⇐ ## Summary of the Pull Request After reading through 114+ comments in #653 and related issues, I think I've finally wrapped my head around all the possible scenarios for quake mode. <!-- Speak now or forever hold your peace. --> This also includes "minimize to tray", because the two are a powerful combination. With the work already prototyped in [`dev/migrie/f/653-QUAKE-MODE`](https://github.com/microsoft/terminal/tree/dev/migrie/f/653-QUAKE-MODE), [I'm starting to believe](https://j.gifs.com/58vKNx.gif) that we could actually land this in 2.0. ### Abstract > Many existing terminals support a feature whereby a user can press a keybinding > anywhere in the OS, and summon their terminal application. Oftentimes the act of > summoning this window is accompanied by a "dropdown" animation, where the window > slides in to view from the top of the screen. This global summon action is often > referred to as "quake mode", a reference to the videogame Quake who's console > slid in from the top. > > This spec addresses both of the following two issues: > * "Quake Mode" ([#653]) > * "Minimize to tray" ([#5727]) ## PR Checklist * [x] Specs: #653, #5727 * [x] References: #5000, #4472, #2227, #7240, #8135 * [x] I work here ## Detailed Description of the Pull Request / Additional comments _\*<sup>\*</sup><sub>\*</sub> read the spec <sub>\*</sub><sup>\*</sup>\*_
zadjii-msft
added a commit
that referenced
this issue
Aug 25, 2021
### ⇒ [doc link](https://github.com/microsoft/terminal/blob/dev/migrie/s/1032-elevation-qol/doc/specs/%235000%20-%20Process%20Model%202.0/%231032%20-%20Elevation%20Quality%20of%20Life%20Improvements.md) ⇐ ## Summary of the Pull Request Despite my best efforts to mix elevation levels in a single Terminal window, it seems that there's no way to do that safely. With the dream of mixed elevation dead, this spec outlines a number of quality-of-life improvements we can make to the Terminal today. These should make using the terminal in elevated scenarios better, since we can't have M/E. ### Abstract > For a long time, we've been researching adding support to the Windows Terminal > for running both unelevated and elevated (admin) tabs side-by-side, in the same > window. However, after much research, we've determined that there isn't a safe > way to do this without opening the Terminal up as a potential > escalation-of-privilege vector. > > Instead, we'll be adding a number of features to the Terminal to improve the > user experience of working in elevated scenarios. These improvements include: > > * A visible indicator that the Terminal window is elevated ([#1939]) > * Configuring the Terminal to always run elevated ([#632]) > * Configuring a specific profile to always open elevated ([#632]) > * Allowing new tabs, panes to be opened elevated directly from an unelevated > window > * Dynamic profile appearance that changes depending on if the Terminal is > elevated or not. ([#1939], [#8311]) ## PR Checklist * [x] Specs: #1032, #632 * [x] References: #5000, #4472, #2227, #7240, #8135, #8311 * [x] I work here ## Detailed Description of the Pull Request / Additional comments _\*<sup>\*</sup><sub>\*</sub> read the spec <sub>\*</sub><sup>\*</sup>\*_ ### Why are these two separate documents? I felt that the spec that is currently in review in #7240 and this doc should remain separate, yet closely related documents. #7240 is more about showing how this large set of problems discussed in #5000 can all be solved technically, and how those solutions can be used together. It establishes that none of the proposed solutions for components of #5000 will preclude the possibility of other components being solved. What it does _not_ do however is drill too deeply on the user experience that will be built on top of those architectural changes. This doc on the other hand focuses more closely on a pair of scenarios, and establishes how those scenarios will work technically, and how they'll be exposed to the user.
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description of the new feature/enhancement
When I work in the terminal (currently mainly CMDer/ConEmu) I like to keep one terminal going with multiple tabs.
When opening a new terminal window, my terminal does not create a new instance of the application but rather opens a new tab in the currently running instance.
Best approach would probably be to make it an option, I.E., not forcing the functionality on people, but rather have it toggle-able for people like me!
Proposed technical implementation details (optional)
Open a terminal while there is a terminal already running opens the running terminal application and creates a new terminal tab, alt. opens the terminal and allows the user to open a new tab manually.
(Love the terminal, it's really neat!)
The text was updated successfully, but these errors were encountered: