Commit graph

6 commits

Author SHA1 Message Date
Dustin L. Howett (MSFT) 214163ebb7
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-24 15:22:40 -07:00
Josh Soref bc6ea11233
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 5740e197c2 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 14:07:04 -07:00
Oisin Grehan 38e7cb0742
Add WT_PROFILE_ID to the environment of the spawned process (#4852)
This commit adds a `WT_PROFILE_ID` environment variable, which contains
the guid of the active profile.

It also teaches ConptyConnection to take an environment map on creation.

We had to do a little manual jiggery with the WSLENV environment
variable as passed by the creator.

* [x] CLA signed
* [ ] Tests added/passed
* [ ] Requires documentation to be updated
* [x] I've discussed this with core contributors already.

Ran terminal, validated vars and translated paths under windows and WSL. 

References #4566 (this PR originally introduced WT_SETTINGS/DEFAULTS)
Closes #3589
2020-04-17 17:15:20 +00:00
Mike Griese d46eead61b
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 13:17:15 -07:00
Dustin L. Howett (MSFT) a09989749a
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-09 15:59:21 -07:00
Dustin L. Howett (MSFT) 52d6c03e64
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 11:35:05 -07:00