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

New Tab Menu Customization #13763

Merged
29 commits merged into from
Dec 9, 2022
Merged

New Tab Menu Customization #13763

29 commits merged into from
Dec 9, 2022

Conversation

FWest98
Copy link
Contributor

@FWest98 FWest98 commented Aug 17, 2022

Implements an initial version of #1571 as it has been specified, the
only big thing missing now is the possibility to add actions, which
depends on #6899.

Further upcoming spec tracked in #12584

Implemented according to instructions by @zadjii-msft. Mostly
relatively straightforward, but some notable details:

  • In accordance with the spec, the counting/indexing of profiles is
    based on their index in the json (so the index of the profile, not of
    the entry in the menu).
  • Resolving a profile name to an actual profile is done in a similar
    fashion as how currently the DefaultProfile field is populated: the
    CascadiaSettings constructor now has an extra _resolve function
    that will iterate over all entries and resolve the names to instances;
    this same function will compute all profile sets (the set of all
    profiles from source "x", and the set of all remaining profiles)
  • Fun fact: I spent two whole afternoons and evenings trying to add 2
    classes (which turned out to be a trivial .vcxproj error), and then
    managed to finish the entire rest of it in another afternoon and
    evening...

Validation Steps Performed

A lot of manual testing; as mentioned above I was not able to run any
tests so I could not add them for now. However, the logic is not too
tricky so it should be relatively safe.

Closes #1571

@ghost ghost added Area-Settings Issues related to settings and customizability, for 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. labels Aug 17, 2022
@FWest98 FWest98 changed the title New Tab Menu Customization #1571 New Tab Menu Customization Aug 17, 2022
@github-actions

This comment has been minimized.

@FWest98
Copy link
Contributor Author

FWest98 commented Aug 17, 2022

On second thought, I only saw #12584 after I implemented my barebones ProfilesSourceEntry. I guess you prefer not to be stuck to this temporary API forever, so maybe it's better to remove that part for now.
Or, if #12584 is finished, it should only take me a few hours to implement it as it stands now, so then we would have a more complete MR here.

Please let me know what you think is best!

@zadjii-msft
Copy link
Member

Thoughts from the dome: I'm fucking jazzed to see this implemented. Definitely one of the biggest feature requests we've had, and I can't wait to see it land.

That being said - we're kinda putting the final wraps on 1.16 at the moment. This PR might take a little while to get merged while we focus on locking 1.16 down. Thanks for bearing with us!

@zadjii-msft zadjii-msft added this to the Terminal v1.17 milestone Aug 18, 2022
Copy link
Member

@carlos-zamora carlos-zamora left a comment

Choose a reason for hiding this comment

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

I couldn't help myself and went ahead and reviewed (most of) it haha. Great work! I just have to review the serialization and TerminalApp changes, but so far it's been really straightforward.

Some feedback:

  • all the stuff in that .github text file should go into .github/actions/spelling/expect/expect.txt
  • you should be able to revert the dep/wil change (I think)
  • honestly, just combine all of the smaller NewTabMenuEntry stuff into the same NewTabMenuEntry files. They're all small enough and like one-liners. Maybe even create a macro like DEFINE_NEW_TAB_MENU_ENTRY that implements the ToJson/FromJson for you.

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.

I'm not through CascadiaSettingsSerialization.cpp quite yet, but figured I'd give feedback sooner than later.

  • Definitely revert the wil change. We moved that dependency to nuget recently.
  • I'd revert the ProfileSource change for now, or break into a separate PR, just so we can definitely merge this ASAP and start kicking the tires.
  • We'll bump Spec for "matching" profiles in "New Tab Customization" #12584 up in discussion priority
  • Meh, spelling nits.

Most of the code so far I'm super cool with. I'm VERY excited to get this merged here at the start of 1.17 ☺️

(The team should feel free to dismiss my block if the checkboxes above get addressed, if my leave starts before I can unblock it myself)

src/cascadia/TerminalSettingsModel/ProfilesSourceEntry.h Outdated Show resolved Hide resolved
src/cascadia/TerminalApp/TerminalPage.cpp Outdated Show resolved Hide resolved
src/cascadia/TerminalApp/TerminalPage.cpp Show resolved Hide resolved
src/cascadia/TerminalSettingsModel/ProfileEntry.cpp Outdated Show resolved Hide resolved
src/cascadia/TerminalSettingsModel/NewTabMenuEntry.cpp Outdated Show resolved Hide resolved
@ghost ghost added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Sep 9, 2022
Copy link
Contributor

@PankajBhojwani PankajBhojwani left a comment

Choose a reason for hiding this comment

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

Excited for this :)

src/cascadia/TerminalSettingsModel/ProfileEntry.cpp Outdated Show resolved Hide resolved
@ghost ghost removed the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Sep 9, 2022
@FWest98
Copy link
Contributor Author

FWest98 commented Sep 10, 2022

Incorporated all your feedback! If there's one reason to upgrade my PC, it would be this project... Easily takes 15-20min for a build after a change in .idl files.

I indeed removed the source item for now, it's easy to get it back by reverting bc628f6 and adapting it later. Hopefully it's nearly done now!

@ghost ghost removed the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Dec 1, 2022
@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@zadjii-msft
Copy link
Member

  • The semantics of having a matchProfiles entry with multiple parameters set is not defined in the spec. As a consequence of the implementation, it now behaves as a disjunction; but I can imagine a conjunction might be preferable from a semantic standpoint.

Whoops, you're right, I didn't ever move #12584 (comment) into the spec itself.

on command line or name, since there will typically be only one match. Only the source matching seems to actually be useful. So we might want to consider supporting regexes straightaway.

That's a great point. I was probably the biggest proponent of regexes for matching on all my "commandline": "cmd /k #work ...." profiles. We've probably got a monthish before we ship 1.17 so we can noodle on that and ship it in a followup if we want. FWIW, I think the source matching is probably what most people were looking for, or at least, will be the most immediately valuable.

@DHowett
Copy link
Member

DHowett commented Dec 6, 2022

FWIW on the topic of regex, we should get this one in first and then iterate 😄

@zadjii-msft
Copy link
Member

FWIW on the topic of regex, we should get this one in first and then iterate 😄

ABSOLUTELY. I want to get this in this week for sure

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.

I really don't want to block over this - I might just push the fix directly to your branch if that's cool, and Dustin signs off soon enough. I want to get these 1.17 features all cleared out of the queue asap.

{
auto isMatching = false;

if (!_Name.empty())
Copy link
Member

Choose a reason for hiding this comment

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

So this is now a union of all the properties, not the intersection. I feel like we should probably make it the conjunction. If it's a disjunction, there's no way to filter on multiple properties at once. If it's an intersection instead, then you can still get a union by just adding one entry per property

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Since it's now a separate function, I'll write a quick fix for it tonight.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Luckily for you, European tonight is already now ;) It should now have conjunction semantics.

@ghost ghost added Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something and removed Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something labels Dec 6, 2022
@zadjii-msft zadjii-msft removed their assignment Dec 6, 2022
@@ -43,22 +43,31 @@ winrt::com_ptr<NewTabMenuEntry> MatchProfilesEntry::FromJson(const Json::Value&

bool MatchProfilesEntry::MatchesProfile(const Model::Profile& profile)
{
auto isMatching = false;
// We use an optional here instead of a simple bool directly, since there is no
Copy link
Member

Choose a reason for hiding this comment

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

I kinda wonder if we want the opposite behavior! Matching with no conditions means everything passes... that would let us simplify the logic as in my farther-down comment

Copy link
Member

Choose a reason for hiding this comment

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

@zadjii-msft Does that make sense to you, or did I countermand you?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not sure, to me it wouldn't feel intuitive that matchProfiles (which I would interpret as a positive match) without criteria would match everything, I would find it intuitive to match nothing. (which is harder to implement indeed)

Copy link
Member

Choose a reason for hiding this comment

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

Huh. I've been thinking about it all night, and honestly both seem alright, so I think we should just pick one and go with it.

Having no conditions match everything kinda makes sense - you start with everything, and each property filters that list down more.

Having it match nothing also makes sense - there's no properties, so that doesn't really make sense as an entry, and then it just gets ignored.

(also, I've got the plague now too so I might need @DHowett to finish driving this one down)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If we do decide for default everything, then naming it filterProfiles makes more sense. So then, matchProfiles to me is default nothing.

Comment on lines 67 to 70
if (!_Commandline.empty())
{
isMatching = isMatching || _Commandline == profile.Commandline();
isMatching = { isMatching.value_or(true) && _Commandline == profile.Commandline() };
}
Copy link
Member

Choose a reason for hiding this comment

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

This could be collapsed to...

if (_Commandline && _Commandline != profile.Commandline())
    return false;

// etc...

return true;

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Only if we want the no-filter case to return all profiles; otherwise this would not work properly.

Copy link
Member

Choose a reason for hiding this comment

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

Okay, I find that I am only really reacting to the optional<bool>. Feel free to dismiss me out-of-hand.

This is an even sillier (but I don't know, more straightforward?) way to handle it.

int conditions = 0, matched = 0;
conditions += _Commandline.has_value();
matched += _Commandline == profile.Commandline(); // nullopt == anything is FALSE

// ...
return conditions == matched;

0 conditions, 0 matches (thanks to all the nullopts) => true.

do I love it? i dunno, not really any more than .value_or(true).

Copy link
Member

Choose a reason for hiding this comment

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

I do generally agree about match vs filter, and I accept that we want match! Sorry, I didn't make that clear. :D

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm I dislike the other setup a bit. Neither way is amazing though, so feel free to pick what you think is best.

@zadjii-msft zadjii-msft dismissed their stale review December 7, 2022 13:54

dismissing myself on account of the plague

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.

I'm gonna say I'm fine with this as is. matchProfiles with nothing returns nothing, that makes sense to me. Additional parameters restrict which things we match on. That makes sense to me.

I'm not locked in to that though - if @DHowett feels passionate the other way, idgaf.

@zadjii-msft zadjii-msft dismissed DHowett’s stale review December 9, 2022 22:39

[3:03 PM] Dustin Howett you can dismiss me and merge it

@zadjii-msft zadjii-msft added the AutoMerge Marked for automatic merge by the bot when requirements are met label Dec 9, 2022
@ghost
Copy link

ghost commented Dec 9, 2022

Hello @zadjii-msft!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

@ghost ghost merged commit 2668273 into microsoft:main Dec 9, 2022
ghost pushed a commit that referenced this pull request Jan 19, 2023
`_Entries` was getting default constructed to `nullptr`. We should be careful about that. 

Adds a test too, and fixes a regression in the local tests introduced in #13763.

Closes #14557
@ghost
Copy link

ghost commented Jan 24, 2023

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

Handy links:

nguyen-dows pushed a commit to MicrosoftDocs/terminal that referenced this pull request Aug 31, 2023
As tracked in microsoft/terminal#1571
As added in microsoft/terminal#13763

This shipped in 1.17 😬 

Closes #667 

_big props to copilot for somehow writing 99% of this for me_
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-Settings Issues related to settings and customizability, for console or terminal AutoMerge Marked for automatic merge by the bot when requirements are met Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Product-Terminal The new Windows Terminal. zBugBash-Consider
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow dropdown menu customization in profiles.json
6 participants