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

Proposal: Add a Opened event in TeachingTip similar to Closed event #1607

Open
mdmozibur opened this issue Nov 13, 2019 · 7 comments
Open

Proposal: Add a Opened event in TeachingTip similar to Closed event #1607

mdmozibur opened this issue Nov 13, 2019 · 7 comments
Assignees
Labels
area-TeachingTip feature proposal New feature proposal team-Controls Issue for the Controls team

Comments

@mdmozibur
Copy link
Contributor

TeachingTip has an Closed event, but surprisingly it doesn't have a similar Opened event.

Please add this event.

@mdmozibur mdmozibur added the feature proposal New feature proposal label Nov 13, 2019
@msft-github-bot msft-github-bot added the needs-triage Issue needs to be triaged by the area owners label Nov 13, 2019
@marcelwgn
Copy link
Contributor

I am surprised that the TeachingTip does not provide such an event. I agree that the TeachingTip should have such an event.

@YuliKl YuliKl added area-TeachingTip team-Controls Issue for the Controls team and removed needs-triage Issue needs to be triaged by the area owners labels Nov 14, 2019
ghost pushed a commit to microsoft/terminal that referenced this issue Apr 2, 2021
## Summary of the Pull Request

This PR adds support for renaming windows.

![window-renaming-000](https://user-images.githubusercontent.com/18356694/113034344-9a30be00-9157-11eb-9443-975f3c294f56.gif)
![window-renaming-001](https://user-images.githubusercontent.com/18356694/113034452-b5033280-9157-11eb-9e35-e5ac80fef0bc.gif)


It does so through two new actions:
* `renameWindow` takes a `name` parameter, and attempts to set the window's name
  to the provided name. This is useful if you always want to hit <kbd>F3</kbd>
  and rename a window to "foo" (READ: probably not that useful)
* `openWindowRenamer` is more interesting: it opens a `TeachingTip` with a
  `TextBox`. When the user hits Ok, it'll request a rename for the provided
  value. This lets the user pick a new name for the window at runtime.

In both cases, if there's already a window with that name, then the monarch will
reject the rename, and pop a `Toast` in the window informing the user that the
rename failed. Nifty!

## References
* Builds on the toasts from #9523
* #5000 - process model megathread

## PR Checklist
* [x] Closes https://github.com/microsoft/terminal/projects/5#card-50771747
* [x] I work here
* [x] Tests addded (and pass with the help of #9660)
* [ ] Requires documentation to be updated

## Detailed Description of the Pull Request / Additional comments

I'm sending this PR while finishing up the tests. I figured I'll have time to sneak them in before I get the necessary reviews.

> PAIN: We can't immediately focus the textbox in the TeachingTip. It's
> not technically focusable until it is opened. However, it doesn't
> provide an even tto tell us when it is opened. That's tracked in
> microsoft/microsoft-ui-xaml#1607. So for now, the user _needs_ to
> click on the text box manually.
> We're also not using a ContentDialog for this, because in Xaml
> Islands a text box in a ContentDialog won't recieve _any_ keypresses.
> Fun!

## Validation Steps Performed

I've been playing with 

```json
        { "keys": "f1", "command": "identifyWindow" },
        { "keys": "f2", "command": "identifyWindows" },
        { "keys": "f3", "command": "openWindowRenamer" },
        { "keys": "f4", "command": { "action": "renameWindow", "name": "foo" } },
        { "keys": "f5", "command": { "action": "renameWindow", "name": "bar" } },
```

and they seem to work as expected
@zadjii-msft
Copy link
Member

If I wanted to contribute this, any ideas where I'd start? Are there any other Opened events that I could crib off of to start with? This is now blocking the downstream a11y bug microsoft/terminal#12021, so we may need to get this in ourselves 😉

@marcelwgn
Copy link
Contributor

You should probably be able to copy the Closing event for the initial set up. After that you probably need to look where in the TeachingTip control it get's opened and then hook into that to raise the event. If there's a way I can help with this, feel free to reach out :)

@zadjii-msft
Copy link
Member

Okay so I gotta wait for the world to build, then build the nuget, then ingest that in a local Terminal build to test, but does this look like I'm on the right track?

main...zadjii-msft:dev/migrie/b/1607-teachingtip-opened

@marcelwgn
Copy link
Contributor

If you want to try your changes with Terminal, yes I think this is the easiest way. You could also try to set up your local Terminal repository to also include the Microsoft.UI.Xaml project so you use the output of that project, but I think I tried that and wasn't so successful. In case you only want to check if it works in general, you can (and maybe should) use the MUXControlsTestApp. Also, really like those commit messages!

@zadjii-msft
Copy link
Member

Well, 4 hours later:

gh-12021-i-did-it

(in that gif, the Terminal has istened to the Opened event and manually yeeted focus into the TextBox, a la https://github.com/microsoft/terminal/blob/4e61be9cd72a578cecd24b2c2d0c17fe7dd9635a/src/cascadia/TerminalApp/AppActionHandlers.cpp#L858)

Looks like it worked. I'm not familiar enough with the edge cases in TeachingTip to say it'll work for sure, but it sure does seem to work.

@marcelwgn
Copy link
Contributor

Awesome @zadjii-msft ! I guess the next step is creating a PR and go over your changes :)

ghost pushed a commit to microsoft/terminal that referenced this issue Mar 31, 2022
Does what it says on the tin. This is maximal BODGE. 

`TeachingTip` doesn't provide an `Opened` event.
(microsoft/microsoft-ui-xaml#1607). But we
want to focus the renamer text box when it's opened. We can't do that
immediately, the TextBox technically isn't in the visual tree yet. We
have to wait for it to get added some time after we call IsOpen. How do
we do that reliably? Usually, for this kind of thing, we'd just use a
one-off LayoutUpdated event, as a notification that the TextBox was
added to the tree. HOWEVER:
* The _first_ time this is fired, when the box is _first_ opened,
  yeeting focus doesn't work on the first LayoutUpdated. It does work on
  the second LayoutUpdated. Okay, so we'll wait for two LayoutUpdated
  events, and focus on the second.
* On subsequent opens: We only ever get a single LayoutUpdated. Period.
  But, you can successfully focus it on that LayoutUpdated.

So, we'll keep track of how many LayoutUpdated's we've _ever_ gotten. If
we've had at least 2, then we can focus the text box.

We're also not using a ContentDialog for this, because in Xaml Islands a
text box in a ContentDialog won't receive _any_ keypresses. Fun!


## References
* microsoft/microsoft-ui-xaml#1607
* microsoft/microsoft-ui-xaml#6910
* microsoft/microsoft-ui-xaml#3257
* #9662

## PR Checklist
* [x] Will close out #12021, but that's an a11y bug that needs secondary
  validation
* [x] Closes #11322
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated

## Validation Steps Performed

Tested manually
DHowett pushed a commit to microsoft/terminal that referenced this issue Mar 31, 2022
Does what it says on the tin. This is maximal BODGE.

`TeachingTip` doesn't provide an `Opened` event.
(microsoft/microsoft-ui-xaml#1607). But we
want to focus the renamer text box when it's opened. We can't do that
immediately, the TextBox technically isn't in the visual tree yet. We
have to wait for it to get added some time after we call IsOpen. How do
we do that reliably? Usually, for this kind of thing, we'd just use a
one-off LayoutUpdated event, as a notification that the TextBox was
added to the tree. HOWEVER:
* The _first_ time this is fired, when the box is _first_ opened,
  yeeting focus doesn't work on the first LayoutUpdated. It does work on
  the second LayoutUpdated. Okay, so we'll wait for two LayoutUpdated
  events, and focus on the second.
* On subsequent opens: We only ever get a single LayoutUpdated. Period.
  But, you can successfully focus it on that LayoutUpdated.

So, we'll keep track of how many LayoutUpdated's we've _ever_ gotten. If
we've had at least 2, then we can focus the text box.

We're also not using a ContentDialog for this, because in Xaml Islands a
text box in a ContentDialog won't receive _any_ keypresses. Fun!

## References
* microsoft/microsoft-ui-xaml#1607
* microsoft/microsoft-ui-xaml#6910
* microsoft/microsoft-ui-xaml#3257
* #9662

## PR Checklist
* [x] Will close out #12021, but that's an a11y bug that needs secondary
  validation
* [x] Closes #11322
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated

## Validation Steps Performed

Tested manually

(cherry picked from commit b57fe85)
Service-Card-Id: 79978834
Service-Version: 1.13
DHowett pushed a commit to microsoft/terminal that referenced this issue Mar 31, 2022
Does what it says on the tin. This is maximal BODGE.

`TeachingTip` doesn't provide an `Opened` event.
(microsoft/microsoft-ui-xaml#1607). But we
want to focus the renamer text box when it's opened. We can't do that
immediately, the TextBox technically isn't in the visual tree yet. We
have to wait for it to get added some time after we call IsOpen. How do
we do that reliably? Usually, for this kind of thing, we'd just use a
one-off LayoutUpdated event, as a notification that the TextBox was
added to the tree. HOWEVER:
* The _first_ time this is fired, when the box is _first_ opened,
  yeeting focus doesn't work on the first LayoutUpdated. It does work on
  the second LayoutUpdated. Okay, so we'll wait for two LayoutUpdated
  events, and focus on the second.
* On subsequent opens: We only ever get a single LayoutUpdated. Period.
  But, you can successfully focus it on that LayoutUpdated.

So, we'll keep track of how many LayoutUpdated's we've _ever_ gotten. If
we've had at least 2, then we can focus the text box.

We're also not using a ContentDialog for this, because in Xaml Islands a
text box in a ContentDialog won't receive _any_ keypresses. Fun!

## References
* microsoft/microsoft-ui-xaml#1607
* microsoft/microsoft-ui-xaml#6910
* microsoft/microsoft-ui-xaml#3257
* #9662

## PR Checklist
* [x] Will close out #12021, but that's an a11y bug that needs secondary
  validation
* [x] Closes #11322
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated

## Validation Steps Performed

Tested manually

(cherry picked from commit b57fe85)
Service-Card-Id: 79978833
Service-Version: 1.12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-TeachingTip feature proposal New feature proposal team-Controls Issue for the Controls team
Projects
None yet
Development

No branches or pull requests

6 participants