maxmustermann/terminal
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
terminal/.github/actions/spell-check/dictionary/apis.txt

12 lines
108 B
Plaintext
Raw Normal View History

specs: draft spec for adding profiles to the Windows jumplist (#5350) _This is literally just #1357, but moved to the `drafts/` folder_. Since @dsafa doesn't have the time to finish this on their own, we'll take it from here for 2.0 ☺️ ## Summary of the Pull Request Adds a spec describing jumplist integration and adding profiles to the jumplist. Includes details about previous investigations into adding the jumplist. ## PR Checklist * [x] Specs #576 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [n/a] 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: #576 ## Detailed Description of the Pull Request / Additional comments Details in the spec. ## Validation Steps Performed N/A Co-authored-by: Brandon Chong <brndnchong@gmail.com>
2020-04-14 22:17:15 +02:00
ICustom
Replace the HRGN-based titlebar cutout with an overlay window (#5485) Also known as "Kill HRGN II: Kills Regions Dead (#5485)" Copying the description from @greg904 in #4778. --- 8< --- My understanding is that the XAML framework uses another way of getting mouse input that doesn't work with `WM_SYSCOMMAND` with `SC_MOVE`. It looks like it "steals" our mouse messages like `WM_LBUTTONDOWN`. Before, we were cutting (with `HRGN`s) the drag bar part of the XAML islands window in order to catch mouse messages and be able to implement the drag bar that can move the window. However this "cut" doesn't only apply to input (mouse messages) but also to the graphics so we had to paint behind with the same color as the drag bar using GDI to hide the fact that we were cutting the window. The main issue with this is that we have to replicate exactly the rendering on the XAML drag bar using GDI and this is bad because: 1. it's hard to keep track of the right color: if a dialog is open, it will cover the whole window including the drag bar with a transparent white layer and it's hard to keep track of those things. 2. we can't do acrylic with GDI So I found another method, which is to instead put a "drag window" exactly where the drag bar is, but on top of the XAML islands window (in Z order). I've found that this lets us receive the `WM_LBUTTONDOWN` messages. --- >8 --- Dustin's notes: I've based this on the implementation of the input sink window in the UWP application frame host. Tested manually in all configurations (debug, release) with snap, drag, move, double-click and double-click on the resize handle. Tested at 200% scale. Closes #4744 Closes #2100 Closes #4778 (superseded.)
2020-04-25 00:22:40 +02:00
IMap
specs: draft spec for adding profiles to the Windows jumplist (#5350) _This is literally just #1357, but moved to the `drafts/` folder_. Since @dsafa doesn't have the time to finish this on their own, we'll take it from here for 2.0 ☺️ ## Summary of the Pull Request Adds a spec describing jumplist integration and adding profiles to the jumplist. Includes details about previous investigations into adding the jumplist. ## PR Checklist * [x] Specs #576 * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA * [n/a] 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: #576 ## Detailed Description of the Pull Request / Additional comments Details in the spec. ## Validation Steps Performed N/A Co-authored-by: Brandon Chong <brndnchong@gmail.com>
2020-04-14 22:17:15 +02:00
IObject
Fall back to TerminalApp.dll's version when we're unpackaged (#5274) This pull request makes sure we still get a usable (for troubleshooting purposes) version number in the about dialog and settings file when the user is running unpackaged. This introduces a magic LCID constant (0x0409).B y default, Package ES emits version resource information that says we're localized to ... language zero. It also emits a language-coded version block for 0x0409 (en-US). These two things cannot both be true. Collapse the wave function by hardcoding 0x0409.
2020-04-10 00:59:21 +02:00
LCID
ci: spelling: update to 0.0.15a; update whitelist (#5413) * Cleaning up the whitelist a bit. * The magic to exclude repeated characters worked 👍 * Every successful run on master now logs its suggested cleanup, e.g. for https://github.com/microsoft/terminal/commit/5740e197c20bea97b0afe4b396d0541691d02b2c has https://github.com/microsoft/terminal/runs/596271627#step:4:37 * ⚠️ This check-spelling 0.0.15a+ tolerates Windows line endings in the `whitelist.txt` file (another project I touched had some `.gitconfig` magic which required supporting them). This means that if someone edits the file w/ something that likes Windows line endings, the file will successfully convert (instead of it being ignored and check-spelling complaining about everything). Most likely anyone else who then edits the file will use something that will maintain the line endings.
2020-04-21 23:07:04 +02:00
NCHITTEST
Replace the HRGN-based titlebar cutout with an overlay window (#5485) Also known as "Kill HRGN II: Kills Regions Dead (#5485)" Copying the description from @greg904 in #4778. --- 8< --- My understanding is that the XAML framework uses another way of getting mouse input that doesn't work with `WM_SYSCOMMAND` with `SC_MOVE`. It looks like it "steals" our mouse messages like `WM_LBUTTONDOWN`. Before, we were cutting (with `HRGN`s) the drag bar part of the XAML islands window in order to catch mouse messages and be able to implement the drag bar that can move the window. However this "cut" doesn't only apply to input (mouse messages) but also to the graphics so we had to paint behind with the same color as the drag bar using GDI to hide the fact that we were cutting the window. The main issue with this is that we have to replicate exactly the rendering on the XAML drag bar using GDI and this is bad because: 1. it's hard to keep track of the right color: if a dialog is open, it will cover the whole window including the drag bar with a transparent white layer and it's hard to keep track of those things. 2. we can't do acrylic with GDI So I found another method, which is to instead put a "drag window" exactly where the drag bar is, but on top of the XAML islands window (in Z order). I've found that this lets us receive the `WM_LBUTTONDOWN` messages. --- >8 --- Dustin's notes: I've based this on the implementation of the input sink window in the UWP application frame host. Tested manually in all configurations (debug, release) with snap, drag, move, double-click and double-click on the resize handle. Tested at 200% scale. Closes #4744 Closes #2100 Closes #4778 (superseded.)
2020-04-25 00:22:40 +02:00
NCLBUTTONDBLCLK
NCRBUTTONDBLCLK
NOREDIRECTIONBITMAP
Patch the default profile and version into the settings template (#5232) This pull request introduces unexpanded variables (`%DEFAULT_PROFILE%`, `%VERSION%` and `%PRODUCT%`) to the user settings template and code to expand them. While doing this, I ran into a couple things that needed to widen from accepting strings to accepting string views. I also had to move application name and version detection up to AppLogic and expose the AppLogic singleton. The dynamic profile generation logic had to be moved to before we inject the templated variables, as the new default profile depends on the generated dynamic profiles. References #5189, #5217 (because it has a dependency on `VERSION` and `PRODUCT`). ## PR Checklist * [x] Closes #2721 * [x] CLA signed * [x] Tests added/passed * [ ] Requires documentation to be updated * [x] I've discussed this with core contributors already ## Validation Steps Performed Deleted my settings and watched them regenerate.
2020-04-07 20:35:05 +02:00
rfind
Add support for setting a tab's color at runtime w/ context menu (#3789) This commit introduces a context menu for Tab and a new item, "Color...", which will display a color picker. A flyout menu, containing a custom flyout, is attached to each tab. The flyout displays a palette of 16 preset colors and includes a color picker. When the user selects or clears color, an event is fired, which is intercepted by the tab to which the flyout belongs. The changing of the color is achieved by putting the selected color in the resource dictionary of the tab, using well-defined dictionary keys (e.g. TabViewItemHeaderBackground). Afterwards the visual state of the tab is toggled, so that the color change is visible immediately. Custom-colored tabs will be desaturated (somewhat) by alpha blending them with the tab bar background. The flyout menu also contains a 'Close' flyout item. ## Validation Steps Performed I've validated the behavior manually: start the program via the start menu. Right click on the tab -> Choose a tab color. The color flyout is going to be shown. Click a color swatch or click 'Select a custom color' to use the color picker. Use the 'Clear the current color' to remove the custom color. Closes #2994. References #3327.
2020-05-04 22:57:12 +02:00
roundf
Replace the HRGN-based titlebar cutout with an overlay window (#5485) Also known as "Kill HRGN II: Kills Regions Dead (#5485)" Copying the description from @greg904 in #4778. --- 8< --- My understanding is that the XAML framework uses another way of getting mouse input that doesn't work with `WM_SYSCOMMAND` with `SC_MOVE`. It looks like it "steals" our mouse messages like `WM_LBUTTONDOWN`. Before, we were cutting (with `HRGN`s) the drag bar part of the XAML islands window in order to catch mouse messages and be able to implement the drag bar that can move the window. However this "cut" doesn't only apply to input (mouse messages) but also to the graphics so we had to paint behind with the same color as the drag bar using GDI to hide the fact that we were cutting the window. The main issue with this is that we have to replicate exactly the rendering on the XAML drag bar using GDI and this is bad because: 1. it's hard to keep track of the right color: if a dialog is open, it will cover the whole window including the drag bar with a transparent white layer and it's hard to keep track of those things. 2. we can't do acrylic with GDI So I found another method, which is to instead put a "drag window" exactly where the drag bar is, but on top of the XAML islands window (in Z order). I've found that this lets us receive the `WM_LBUTTONDOWN` messages. --- >8 --- Dustin's notes: I've based this on the implementation of the input sink window in the UWP application frame host. Tested manually in all configurations (debug, release) with snap, drag, move, double-click and double-click on the resize handle. Tested at 200% scale. Closes #4744 Closes #2100 Closes #4778 (superseded.)
2020-04-25 00:22:40 +02:00
SIZENS
Reference in a new issue Copy permalink