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

Move Tab Switcher mode handling into CommandPalette #8656

Merged
4 commits merged into from Jan 19, 2021

Conversation

Don-Vito
Copy link
Contributor

A part of the #8415.
Includes:

  • Moving TabSwitcherMode related decisions into CommandPalette
    (simplifying the logic of TerminalPage::SelectNextTab)
  • Fix a bug where the index of first tab switch is incorrect
    (since bindings are not updated)
  • Removing redundant CommandPalette updates
  • Preparations for tabs binding

@zadjii-msft zadjii-msft self-assigned this Jan 4, 2021
Copy link
Member

@zadjii-msft zadjii-msft left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are some smaller questions, nothing too major IMO

src/cascadia/TerminalApp/TerminalPage.cpp Show resolved Hide resolved
Comment on lines -891 to -876
// Some callers might actually want smooth updating, like when the list
// of tabs changes.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this mean that now, if a tab is removed which the switcher is open, that the entire list will re-animate into existence, rather than the smooth update it does now?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now if the tab is removed our ephemeral palette gets closed immediately 😊

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm okay with this

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe that's because of the earlier change to dispatch bindings from TerminalPage::PreviewKeyDown, right? That makes sense to me.

But... does this also hold if a user (trying to break terminal :P) issues a sleep 5; exit and then opens up the palette and waits for it to blow up?

Copy link
Contributor Author

@Don-Vito Don-Vito Jan 18, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@DHowett - what a nasty user 😊 I believe that the problem you describe exists in the original code as well.

From my understanding, If the user triggers delayed sleep and then starts switching, what will happen right now is that we will still have TabPaletteItem populated in the switcher, but switching to it will have no action (as weak ref is empty). Not perfect, not terrible (or however they said this in Chernobyl). To resolve this we need to have the fully fledged binding that I planned for the next PR (where we do follow the changes in _tabs, _mruTabs that are observable collections).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@DHowett - ignore the previous comment. What happens now, if the tab is closed by sleep 5; exit we actually dismiss the switcher. This was introduced as a part of the ephemeral palette work (every change in tabs collection closes the palette) to ensure consistency. If the user tries to break terminal this way, the only impact that the palette gets closed.

@zadjii-msft zadjii-msft removed their assignment Jan 7, 2021
Copy link
Member

@zadjii-msft zadjii-msft left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay this is better than before, esp for TabSearch - it reanimates less, which is good!

@zadjii-msft zadjii-msft removed their assignment Jan 15, 2021
@zadjii-msft zadjii-msft added Area-CmdPal Command Palette issues and features Area-User Interface Issues pertaining to the user interface of the Console or Terminal Product-Terminal The new Windows Terminal. labels Jan 15, 2021
Copy link
Member

@DHowett DHowett left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Totally gonna sign off, but had a couple q outstanding. 😄 Thanks for cleaning up our command palette, @Don-Vito!

Comment on lines 969 to 972
for (uint32_t index = 0; index < commandsToFilter.Size(); index++)
{
actions.push_back(commandsToFilter.GetAt(index));
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: is this transformable to a std::copy with a back_inserter? I remember Carlos and I had a similar discussion on the Settings editor UI

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@DHowett - semantically, yes 😊 Technically, I am not sure how to do it because commandsToFilter is an IVector. Is there a way to get the underlying vector / iterator for it?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This works, but I have no idea why. VS won't tell me exactly where begin and end originate.

	std::vector<winrt::hstring> vec{ L"One", L"Two", L"Three" };
	auto f = winrt::single_threaded_vector(std::move(vec));
	Collections::IVector<winrt::hstring> projectedVector{ f };

	std::for_each(begin(projectedVector), end(projectedVector), [](auto&& val) {
		std::wcout << std::wstring_view{ val } << L"\n";
	});

I'm not using namespace winrt::impl, but here we are in 2021 and all signs point to that I am using begin/end directly out of winrt::impl.

Copy link
Contributor Author

@Don-Vito Don-Vito Jan 18, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is absolutely cool! Is it documented somewhere? 😄
So begin and end are a part of Windows.Foundations.Collections.h - nice!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I can tell, it's a language feature (!) that in part is used to support range-based for loops. I've been digging for documentation (and trying to figure out how it works), but it has been difficult.

Copy link
Contributor Author

@Don-Vito Don-Vito Jan 18, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

C:\Users...\Documents\GitHub\terminal\src\cascadia\TerminalApp\Generated Files\winrt\Windows.Foundation.Collections.h

template <typename T, std::enable_if_t<has_GetAt<T>::value, int> = 0>
    fast_iterator<T> begin(T const& collection) noexcept
    {
        return { collection, 0 };
    }

    template <typename T, std::enable_if_t<has_GetAt<T>::value, int> = 0>
    fast_iterator<T> end(T const& collection)
    {
        return { collection, collection.Size() };
    }

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, but if nobody is using namespace winrt::impl (which they tell us is private 😉), those definitions shouldn't be found when they're not namespace-qualified. Yet this works.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it! This is clever. Argument-dependent lookup (ADL) specifies how free functions are resolved (based on their argument types). One of the steps in argument-dependent lookup is the collection of the class hierarchy and the namespaces of the classes in that hierarchy.

Because each C++/WinRT projection type inherits from something in winrt::impl, ADL on projection types finds any free functions inside the impl namespace. If they didn't inherit from winrt::impl, winrt::impl::begin would not be found.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is really clever.. but it also makes the modern c++ extremely challenging to code review IMHO.

@Don-Vito Don-Vito requested a review from DHowett January 18, 2021 21:01
Copy link
Member

@DHowett DHowett left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the command palette doesn't observe the vector passed in to SetTabs, we could weaken the contract to IVector<TabBase> from IObservableVector<TabBase> and undo the changes in TerminalPage that make _mruTab observable. I'm not blocking on this, but if you want to do it I'll be holding off the merge 😄

@DHowett
Copy link
Member

DHowett commented Jan 18, 2021

@msftbot merge this in 24 hours

@ghost ghost added the AutoMerge Marked for automatic merge by the bot when requirements are met label Jan 18, 2021
@ghost
Copy link

ghost commented Jan 18, 2021

Hello @DHowett!

Because you've given me some instructions on how to help merge this pull request, I'll be modifying my merge approach. Here's how I understand your requirements for merging this pull request:

  • I won't merge this pull request until after the UTC date Tue, 19 Jan 2021 22:17:30 GMT, which is in 1 day

If this doesn't seem right to you, you can tell me to cancel these instructions and use the auto-merge policy that has been configured for this repository. Try telling me "forget everything I just told you".

@Don-Vito
Copy link
Contributor Author

Don-Vito commented Jan 19, 2021

Since the command palette doesn't observe the vector passed in to SetTabs, we could weaken the contract to IVector<TabBase> from IObservableVector<TabBase> and undo the changes in TerminalPage that make _mruTab observable. I'm not blocking on this, but if you want to do it I'll be holding off the merge 😄

@DHowett - this is actually a preparation. I am going to submit a PR, where cmdpal observes these collections (and we will set them only once). This will be a next step towards filterable list view

@ghost ghost merged commit f196285 into microsoft:main Jan 19, 2021
@ghost
Copy link

ghost commented Jan 28, 2021

🎉Windows Terminal Preview v1.6.10272.0 has been released which incorporates this pull request.:tada:

Handy links:

mpela81 pushed a commit to mpela81/terminal that referenced this pull request Jan 28, 2021
A part of the microsoft#8415.
Includes:
* Moving `TabSwitcherMode` related decisions into `CommandPalette`
(simplifying the logic of `TerminalPage::SelectNextTab`)
* Fix a bug where the index of first tab switch is incorrect
(since bindings are not updated)
* Removing redundant `CommandPalette` updates
* Preparations for tabs binding
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-CmdPal Command Palette issues and features Area-User Interface Issues pertaining to the user interface of the Console or Terminal AutoMerge Marked for automatic merge by the bot when requirements are met Product-Terminal The new Windows Terminal.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants