Fix TermControl initialization to pre-seed working dir

[Don-Vito]

PR Checklist

• Closes Terminal's working directory (i.e. for duplicate tab) does not default to the startup directory being used #8969
• CLA signed.
• Tests added/passed
• Documentation updated.
• Schema updated.
• I've discussed this with core contributors already.

Detailed Description of the Pull Request / Additional comments

Validation Steps Performed

[Don-Vito]

@skyline75489 - can you please take a look that I am not ruining stuff? 😊

[skyline75489]

That's a good one-liner fix. I'm OK. Just want to make sure if this is @DHowett wants.

[DHowett]

I think this is the wrong way around— we’re telling TermControl that an OSC 9;9 occurred using its internal API so that it calls TermControl’s working directory handler to trigger the working directory event. Can TerminalApp just handle this at the top layer? :)

[DHowett]

Discussion

[Don-Vito]

Discussion

@DHowett - I am afraid I failed to follow the part with directory handler. My understanding wast that _workingDirectory in TerminalApi is just a container for the source of truth.

[skyline75489]

I think what Dustin says is to add new event for "working directory change" and a callback for that event, like we did for title change ("pfnTitleChanged") and the other things.

[skyline75489]

Well, due to my laziness, there's no such event at the moment. Or I'm misunderstanding Dustin. I'm still in the bed probably not really thinking straight 😅

[Don-Vito]

Well, due to my laziness, there's no such event at the moment. Or I'm misunderstanding Dustin. I'm still in the bed probably not really thinking straight 😅

There is no such event, and actually I am also confused.

We could probably manage _workingDirectory on a higher level than in Terminal, in the first place, i.e., to introduce some event in Terminal and forward it to the TerminalApp. In this case the source of truth would reside in the app. However currently it is in Terminal.

[zadjii-msft]

Yea I'm confused too. This is exactly how I would've done it... But Dustin is out for the next couple days, so we'll see what he has to say

[Don-Vito]

Yea I'm confused too. This is exactly how I would've done it... But Dustin is out for the next couple days, so we'll see what he has to say

Let's leverage Dustin's absence to push some shitty code! 💃

[DHowett]

Thanks for the explanation! Chester is right- I thought that we had an event that fired out of the control to alert the application.

In general, I find myself unhappy with the number of places we use TerminalSettings/CoreSettings/ControlSettings to communicate state from TerminalApp back to TerminalApp. Know what I mean?

Is the StartingDirectory a Core setting, or is it a control setting? If it’s a core setting, there is probably a different place we should be propagating it in. Using a Control setting to have Control tell Core something seems like it’s also the wrong speed.

None of these are complaints or concerns about the work you’ve done here, @Don-Vito! Just musing 😄

[zadjii-msft]

Oh okay that makes sense then

[ghost]

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]

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

Handy links:

• Release Notes
• Store Download

[ghost]

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

Handy links:

• Release Notes
• Store Download