-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
New Tab Menu Customization #13763
Conversation
Added better rendering logic in TerminalPage Better JSON parsing with inheritance And fixed the tricky vcxproj definition....
Add ProfilesSourceEntry to select all profiles from a given source
This comment has been minimized.
This comment has been minimized.
On second thought, I only saw #12584 after I implemented my barebones Please let me know what you think is best! |
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! |
There was a problem hiding this 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 sameNewTabMenuEntry
files. They're all small enough and like one-liners. Maybe even create a macro likeDEFINE_NEW_TAB_MENU_ENTRY
that implements the ToJson/FromJson for you.
There was a problem hiding this 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 tonuget
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)
.github/actions/spelling/expect/8cf56971f61ef4c0d9d6fedd478821ea33f2d6c4.txt
Outdated
Show resolved
Hide resolved
src/cascadia/TerminalSettingsModel/CascadiaSettingsSerialization.cpp
Outdated
Show resolved
Hide resolved
.github/actions/spelling/expect/8cf56971f61ef4c0d9d6fedd478821ea33f2d6c4.txt
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excited for this :)
Co-authored-by: Mike Griese <migrie@microsoft.com>
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 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! |
This comment has been minimized.
This comment has been minimized.
Appease the spellbot, hopefully
This comment has been minimized.
This comment has been minimized.
Whoops, you're right, I didn't ever move #12584 (comment) into the spec itself.
That's a great point. I was probably the biggest proponent of regexes for matching on all my |
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 |
There was a problem hiding this 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()) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
@@ -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 |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
if (!_Commandline.empty()) | ||
{ | ||
isMatching = isMatching || _Commandline == profile.Commandline(); | ||
isMatching = { isMatching.value_or(true) && _Commandline == profile.Commandline() }; | ||
} |
There was a problem hiding this comment.
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;
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 nullopt
s) => true.
do I love it? i dunno, not really any more than .value_or(true)
.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
dismissing myself on account of the plague
There was a problem hiding this 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.
[3:03 PM] Dustin Howett you can dismiss me and merge it
Hello @zadjii-msft! Because this pull request has the 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 (
|
🎉 Handy links: |
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_
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:
based on their index in the json (so the index of the profile, not of
the entry in the menu).
fashion as how currently the
DefaultProfile
field is populated: theCascadiaSettings
constructor now has an extra_resolve
functionthat 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)
Funfact: I spent two whole afternoons and evenings trying to add 2classes (which turned out to be a trivial
.vcxproj
error), and thenmanaged 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