The Changelog: Software Development, Open Source - Making Windows Terminal awesome (Interview)

Episode Date: July 31, 2020

Kayla Cinnamon, Program Manager at Microsoft for Windows Terminal, Console, Command Line, and Cascadia Code joined us to talk about the release of Windows Terminal 1.0 and the new Windows command-line experience. We talk about everything that went into rethinking the command line experience on Windows, the UX and UI design behind it all, the learnings of working in open source, and what's to come for the Windows command line experience.

Well, since you brought up unification, I'm going to give you a feature request that will unify the experience across WSL and Windows. And I'm fully realizing this might be more of a file system concern, but if y'all could support forward slash for your directory separators versus a backward slash, I think you'd have developers around the world rejoicing at the unified view of directories and the command line with forward slashes. What do you think about that? I think I've heard that one before, definitely. Well, I'm certainly not the first one to have desired it. I don't know who to ask for that. I think there's like a solid

backward compatibility reason why we can't do that. I'm sure there is. I don't quite know, but I feel like we would have done it by now if we could. Being with her changelog is provided by Fastly. Learn more at fastly.com. We move fast and fix things here at changelog because of Rollbar. Check them out at rollbar.com and we're hosted on Linode cloud servers. Head to linode.com slash changelog. Linode makes cloud computing simple, affordable, and accessible. Whether you're working on a personal project or managing your enterprise's infrastructure, Linode has the pricing, support, and scale you need to take your ideas to the next level. We trust Linode because they keep it fast and they keep it simple. Check them out at leno.com slash changelog.

All right, welcome back, everyone. This is the ChangeLog, a podcast featuring the hackers, the leaders, and the innovators in the world of software. I'm Adam Stachowiak, Editor-in-Chief here at ChangeLog. On today's show, we're talking to Kayla Sineman, Program Manager at Microsoft for Windows Terminal for windows terminal console command line and also cascadia code today we're focusing on windows terminal and their recent 1.0 we talk about everything that went into rethinking the command line experience on windows the ux and the ui design behind it all the learnings of working in open source and what's to come for the Windows command line experience. So we're here with Kayla Cinnamon, and we're talking about the cool thing, right? The new Windows Terminal.

It's the new command line experience. It's recently 1.0, which is super cool. Welcome, Kayla. Thanks for having me. I reached out to you, I think, was it in April, I want to say, prior to the 1.0 release? I think it was like 0.9, and you've got monthly releases and monthly blog announcements and stuff like that.

So you've been pretty busy. Yeah, we still release monthly. And now we have two different builds that we push to. We have a preview build and the stable build from Microsoft build. That's a lot of builds. A lot of builds. Yeah. So we push like an incremental update, like 1.1 to preview. And then once that's baked and preview and a lot of the bugs are ironed out, then we'll move it over to stable. So that's kind of our process right now. So the latest is 1.1 moving to stable and 1.2 coming to preview. This is about a year old, right? So Windows Terminal 1.0 now, but it obviously started at

zero or nothing, no version. It was about a year ago, I think it was 2019 build. You announced this, is that right? Yep. So yeah, at Microsoft Build 2019 2019 we announced it in a keynote i think it was rajesh jah's keynote and we had the whole promo video and it was funny because we had to cover our booth name until that keynote happened so we were just kind of awkwardly standing there representing a windows subsystem for linux until our announcement came out because we couldn't like talk about it. So it was just kind of funny because we put a black piece of paper over our booth name. It was just kind of funny. But yeah, so we announced then and announced it as like the new experience. Like this is the new thing for Windows command line. Why is the Windows terminal

an important project at Microsoft for the company and for you personally? Why do you want to work on it? So for like command line experience on Windows, no one's really touched it or changed it in like 30 to 40 years coming up. It's a long time. It's funny because like a ton of developers use it daily. And it's just this old tool that nobody messed with. Because if we changed too many things, then we would break some automated process that needed to launch the console window in a certain place on the screen with certain padding and font size. And if we changed any of that, those processes would break and then we would get in trouble. So that's kind of why we had to start a new terminal

and get a whole fresh new experience. And since this is people's daily driver, they're in the command line all the time, it's something that needs to be refreshed and maintained. So that's why it's important. And then for me, why I really like working on it is I was brought onto the team for the UI, so designing the tabs and how everything looks and how people will interact with it.

So that was just – it's cool for me because I worked with very few people, so I have a lot of stake in what it looks like. So I felt like I made a lot of impact, and then a lot of people have started using it. So it's pretty cool for me to see the impact that I've made as an individual on the team, which is really cool. You also have a master's degree in that stuff too, human computer interaction. So it's something you can really go back to theory and science around the thing too. Yeah. And like all the books I've read and how, like I did a lot of web design and like mobile design and how things are more intuitive when of web design and like mobile design and how

things are more intuitive when they're placed on certain places on the screen or like contrast colors and all that fun stuff. So it's cool that my study is related directly to my role. Yeah. Which is really cool. Yeah. Even more so how important, you know, reviving something that hadn't been touched, as you had said, like 30 or 40 years. I mean, to get a chance to touch something that's such a, I don't know, like a daily driver for developers, you know, like it's a big deal to revive it. Yeah, absolutely. And it was funny when I came on the team, they're like, you're going to do the UI for the command line. And I'm like, isn't the command line literally the opposite of the UI? Like, isn't it's just the black box. And then it was kind of a challenge of how do I bring in, like my knowledge and making it still the command line and you know,

as minimal as possible, but still useful. So that was just kind of interesting, because at first I was like, isn't that the point is that there isn't a UI? So yeah, it was just a really cool challenge to apply to the project. So what kind of UI is there? There's the tab strip on the top, which is the biggest part of the UI. I worked directly with the WinUI team and they basically made the tab control for terminal. So I worked with them of like, here's what we'll need. Here's, you know, some designs that we've thought of and then worked with them for designs that they've thought of. And then that's kind of how the tab strip came to be. And then we implemented stuff like the

dropdown after that, which was already built in. And now the stuff I'm working on, I'm designing the settings UI. So I have like full control over what that looks like. And then any UI element on Terminal. So the search box, I also did by hand. So there's just like a few smaller things, So I have like full control over what that looks like. And then any UI element on terminal. So the search box, I also did by hand. So there's just like a few smaller things, but it's still as minimal as possible. Like if you take the tab strip off, it's just the box. So yeah, it's an interesting challenge. It looks like you're also working on some stuff.

A lot of times the UI, well, UX and UI are different, but can be intertwined. And a lot of that experience or the way you interact with the program is the integration into the other aspects of the operating system. So I see you're adding things like alt click to open a pane. And you're also adding, what's the one that seemed more like an integration? Oh, yeah, open in Windows Terminal. So right click from the context menu, their Integrations into the broader OS, which aren't exactly UI. I mean, they do have their own interfaces, but they're definitely really tying it in and making it accessible and available where you need it. Yeah, and our goal is to make it as intertwined and ingrained in Windows as possible

so it doesn't feel like a separate app anymore. It feels like you're just launching the command line and it's just in Windows as possible. So it doesn't feel like a separate app anymore. It feels like you're just launching the command line and it's just in Windows Terminal. So eventually we want it to be like a default setting. So like when you launch CMD, it will come out in Terminal. So that's a goal that we have. I think it's on our 2.0 roadmap. So we're aiming to get that in by 2.0, but then it would feel like part of Windows rather than this extra terminal emulator I installed on the side and I can only launch it from launching Windows Terminal

rather than the traditional ways that you do it on Windows. Well, totally that back from being there today where you can at least opt in, maybe not by default on new installs, but opt into the new one when you launch the command executable. Since this is a Windows change, we have to wait for the Windows release cycles to go through,

which are much less frequent. So we're working with that release cycle, which is why it's taking a little bit longer. Makes sense. Where did you draw inspiration from when it comes to rethinking? Having touched something that's that dated, I'm wondering, did you scrap all the things? Did you begin brand new? What was the state of the slate when you actually started to make new things for Windows Terminal?

So we are actually using a lot of the code that's already in Windows for the original console because we own both. Our team owns both the original experience and Terminal. So a lot of the code that lets you, it reads from the shell any responses of like text going in, text going out, and then processing it, all of that code is reused in Windows Terminal. I think you can actually see it if you go into Task Manager and you see what's running for Terminal, you should be able to see like Conhost, and then that is the same thing that would be running in a regular console. So we've used that in terms of receiving data from the shell, and then on top of that, we built our own renderer.

So we're able to render things like emojis or other Unicode characters, UTF-8 characters from other languages, coding ligatures, all that stuff. And then we've also utilized the GPU for that renderer. So it's a lot faster. This is actually like a fun fact. If you're running a build and it's in original console and the text is appearing on the screen, it will actually go faster if you minimize the console because it's using a lot of your CPU, which is just like a funny thing. So if you want to build something faster and you're in original console, just minimize the window. But yes, we use the GPU for our renderer. So that was like a new thing on top. And then on top of that, we've added the XAML elements of the tab strip and then the dropdown. So we took what we already had instead of reinventing the wheel, because that

has been battle tested for 30 to 40 years. Now we just needed to change the Chrome around it. So that's kind of where the divide happened. Was a lot of this bringing many worlds together, you know, command prompt, PowerShell, you know, WSL in terms of profiles and stuff like that. Was it more of like, let's make a new experience, a new world for all these things to play well together and unify the experience? Is that what the goal was? Yeah, especially because with WSL, people will use both Ubuntu and PowerShell. And the way it was originally, it's window on top of window, regardless of you have two PowerShell. And the way it was originally, it's window on top of window, regardless of you have two PowerShell windows or two Ubuntu windows or something. So this was just easier in terms of

managing those windows and having it all be in the same UI and then giving more exposure to stuff like Windows subsystem for Linux. Because if you downloaded Ubuntu and maybe forgot about it, or you didn't know you could put it in Terminal any other shell you wanted like an SSH client you could put in there so it would launch your SSH connection in a profile or if you wanted to run a batch script you could do that so it's just kind of unifying what it means to be a command line application on Windows which is pretty neat and then it's like your go-to place you don't have to think of like oh this project is over here in this application. I need to go launch that in a separate window.

It's kind of just bringing your workflow together, which is really nice. Well, since you brought up unification, I'm going to give you a feature request that will unify the experience across WSL and Windows. And I'm fully realizing this might be more of a file system concern, but if y'all could support forward slash for your directory separators versus a backward slash, I think you'd have developers around the world rejoicing at the unified view of directories and the command

line with forward slashes. What do you think about that? I think I've heard that one before, definitely. Well, I'm certainly not the first one to have desired it. I don't know who to ask for that. I think there's like a solid backward compatibility reason why we can't do that. I'm sure there is. I don't quite know, but I feel like we would have done it by now if we could. That's just where I think it would happen. But like our teams are not, we would not be the right place for fixing that.

I think that's like a hardcore Windows. No, that's like a file system thing. Yeah. Yeah, Microsoft's dogged pursuit of backwards compatibility definitely makes changes like that darn near impossible. If you think replacing cmd.exe is tough, I'm pretty sure that just the assumption that the directory separators will be

backslashes is probably hard-coded into millions of programs around the world yeah but it'd be pretty sweet yeah and we yeah like what you were saying we can't ever get rid of cmd.exe because of all that backward compatibility stuff right and we can't change the default of like you have to enable terminal in your settings to be default eventually because some people or if it's like automatically launched by an application it wouldn't be in terminal for those backward compat reasons so there's like a you know a little dance we have to do around those kinds of situations where the window has to appear as it was 30 years ago because whoever wrote that code is no longer around,

but it's not broken, so no one's going to go mess with it. So we have to make sure that we don't break a ton of people when we do this. Which makes it even harder to talk to people like Jared who want that or suggest things like that, and you can't do it, so you've got these... We're just unreasonable people. What I mean by that is that it makes your job even more difficult to you know kind of go into a new era for something that has been tried and true for so long so stable for so long but you know kind of wrap everything else into one and bring a unified experience given you know

like these constraints that that sort of to some degree seem to hold you back a little bit. Did you experience that a lot? Or is there like a list of things like, these are all my constraints. Like we can't, we just can't like do the, you know, cmd.exe for example. Yeah. I think when I joined, I was like, Oh, can't we do this? Cause I, you know, I didn't know anything. I was fresh out of college. And they're like, no, because, you know, backward compatibility. I'm like, okay. I'm like, what about this? And they're like, no. So it's, you start to learn like, okay, there's only certain things we can mess with or certain experiences that we could change. And then you kind of understand the full picture of like, okay, this is something that's heavily relied on between

not only people, but systems and, you know, code that just executes. So it's, it's interesting that you're no longer dealing with only people you're dealing with computers interacting with your own thing, which is just a whole nother way to think about it, which is kind of cool. Was it frustrating or was it one of those things where you have constraints? It's like, this is a challenge or it was like, oh my gosh, one more thing I have to dance around. Yeah, I definitely looked at it as more of a challenge. I'm like, okay, well, if we can't do it this way, how do we resolve this pain point without breaking all that other stuff? So I definitely saw it as like, let's find a different way to do it because there's always a way to do something. So it's just kind of like figuring out how which is fun i think it's a fun part of

the job when it came to new design interactions and ui when you thought about stuff like that how did you how did you research or feel good about directions you wanted to take things that you have a cohort of people that you relied upon for information did you have like you know was the preview like tried and true for you to really learn? Did you ship with something kind of scrappy that eventually turned more, you know, useful? How did it work out? So when I joined in February of last year, the team had a lot of stuff kind of already figured out. They just needed the UI on top. And they've, you know, we've owned, I say they, but it's we now, but we've owned original console for a while.

And some changes were made about three to four years ago. And then after that, people started asking for, you know, background images and GIFs and color support and font support and all that fun stuff. So a lot of the data was coming from requests like that. And then we started molding the terminal into things that everyone has been asking for for multiple years. And Rich always told me, Rich Turner, he said, like, oh, I get emails all the time about, you know, this feature or this feature. And that's kind of how we were able to figure out things to put in there. Plus, what's really cool about Terminal is that it's a product for developers

and the team is made of developers. So if the devs on the team don't find something useful or they don't like it or, like like it's not a use case it's kind of nice to just sample size from our own team because they are developers and they use it to develop it which is just kind of like a funny inception thing so that's kind of where our sample pool came from and a lot of stuff was on twitter and like tweets that rich was getting and then it molded, let's just get something functional out. So the first like Windows Terminal 0.2, not pretty. It's really gross looking. We had like a

really big plus button. You couldn't drag the title bar. It was like, it was really like duct tape and Popsicle sticks. Like it was really held together by not too much. So then we were able to have people start testing it and building it and start developing on it. And then issues are being filed on GitHub. And then we ranked our priority list of features based on responses on GitHub. So then it kind of went from, here's the stuff that we knew we wanted from the last three years. Now that things are in motion and you can open the dropdown and get a new tab, like that worked. It just looked really gross.

It looks much better now. Once we got that basic functionality in, then it turned into, what are people requesting on GitHub? What are people requesting on Twitter? And then what are we wishing we had? I wanted a settings UI since like day one. And I've made like three different designs of it.

And my hackathon project was like coding it. And it was like we've just wanted the settings UI for a really long time. It's just more of like dev resources of let's get it working first and then add the niceties on top like a UI and stuff. So that's kind of how we operate in terms of getting features and stuff. It's a lot of what are the top most reacted to GitHub issues and what's the most duplicated issue that we get coming in. And then we aggregate lists of these things and that's kind of what forms our roadmap after that. So it's really a community driven thing, which is really cool because then we just kind of

give people what they want, which makes us feel really good. And then it's also stuff that we want. So it's really just a nice ecosystem that we have. So that's the process. When dealing with application performance, you ask questions like which endpoint is triggering memory increases? Are slow requests to a particular endpoint cascading to the app? Why is this endpoint slow for only a handful of users? Has this performance pattern occurred before? What changed since the most recent deploy? Those are just a few questions easily answered by Scout APM.

Scout is application monitoring that continually tracks down M plus one database queries, sources of memory bloat, performance abnormalities, and a ton more. Thousands of engineers trust Scout APM to help them uncover performance issues you can't see in the charts. Learn more and get started for free at scoutapm.com slash changelog. No credit cards required. Again, scoutapm.com slash changelog. So let's talk about the design process of things. I mean, when you think about search you'd mentioned, when you think about leading with function and then coming back and layering on form, what's your personal design process? Do you have a team? it are you running Rogan Solo what's the process for designing the interface so when we first started we first were you know

designing terminal itself I worked with a designer at Microsoft and we worked together on here's you know functionality that we want here's like the gist and I had some mock-ups that I made and then he made it look like an actual Microsoft product because I was only there like two months at this point. So I didn't really know what I was doing. And then we were only able to work with him until when we announced in 2019, when we first announced. So then from there, I've just been kind of on my own in terms of designing. So I use Figma. And what's nice about Figma is that there's packages you can get that are like Microsoft controls. So like check boxes and switches and,

you know, close buttons and all that stuff. You can make stuff look like it's a real Microsoft application because it will eventually. So my process, like for the search box, for example, I looked at Visual Studio and Visual Studio Code to see how they did it and how it worked. Because a lot of stuff that we operate on, we try to make very similar to VS Code so that it feels like it's, you know, you're using a Microsoft thing. Yeah. So rather than like, it feels like two different teams made this, which, you know, two different teams are making them, but you want it to feel like a unified experience. So we try to follow a lot of what VS Code has already done. So I modeled the search box after kind of what they've done and then change it to stuff that is available in like

the XAML controls gallery. We do use one UI XAML for all of our UI elements. So I used those controls from the Figma package to design kind of what it would look like. And the functionality piece of it, a lot of it came from how to search work in console. And then what else can we add on top that's like familiar to like VS code users. And then that's kind of the process. And then I just show the team and I'm like what do you think and they're like looks great and I'm like cool go code it they're like awesome and that's like the process so it's pretty like one man job right now so for the settings UI I've been speccing this is the stuff I've been working on lately and doing the mock-ups. So a lot of the stuff is from

what XAML, like the, when UI XAML controls are, and then it's just in terms of like layout and organization and how does it feel as a user, what navigation makes sense for the settings UI and where would I think like font face would be in terms of like a setting and like that kind of layout, that's the stuff I've been tackling now. But in terms of like a setting and like that kind of layout. That's the stuff I've been tackling now, but in terms of like what it looks like, it's pretty standardized to the when UI controls, because we just use their toolkit. Yeah.

What a thing Figma must have done though, for not saying that you're not a designer or an interface person, but from an interaction standpoint, you know, you may have less deeper experience and knowledge around interface and maybe in particular Windows interface design. of focus, which is like interaction, user experience, flows, you know, user desires, as you mentioned, people emailing about different things like, hey, I want this feature or that feature and kind of giving them what they want, as you said. You know, that's such a cool tool to use. We don't have to like be the interface designer, but still be the interface designer.

Right. Yeah. So I like to think of it as like a graphic designer would make what the check boxes look like or what, you know, the font face would look like and stuff like that. And then I would do more layout and experience of like what it feels like to use the application and where stuff is organized and then making sure the colors line up and it's cohesive. That's kind of where I come in, which is really nice because I'm not a graphic designer. I can't make icons.

My art is really, really bad. So it's nice that that's kind of already done for me and I'm just organizing everything in a way that makes sense in terms of the user experience standpoint. So my own terminal, personal terminal path, actually OS path, so I started in Windows and then in college I went to Ubuntu on my laptop and then I went back to Windows as I entered the college I went to Ubuntu on my laptop. And then I went back to Windows as I entered the workforce,

and I ran that for a few years. And then I went to macOS, and that's where I live today. And over the years I've considered going back to Windows from time to time, just as everybody looks at the grass, it's greener, right? And my response to the reasons why I stopped was like well they just don't care about the terminal which is pretty much the main thing i care about the reason why i ran i switched to mac os because it was just like linux only had a nice ui like that was pretty much it done so and i didn't have to keep reinstalling my what was it the wireless cards drivers every time the

system updated my you know on ubuntu back in the early 2000s, it would just destroy your wireless as soon as you upgraded anything. So I got sick of doing that. And I was like, well, Microsoft just doesn't care about the things that I care about, which was the terminal, the command line, that experience specifically.

I would also argue the forward slashes. Just kidding. Just bringing that back up. Windows subsystem for Linux was the first time where I started to change my mind. And I was like, not change my mind about Microsoft, but realize that Microsoft had kind of changed its mind about developers from my perspective.

And I mean, this renewed interest in the terminal and this rewrite from the ground up is more evidence that Microsoft really cares about these things now. And I'm just curious how the developer sphere received your big 1.0 and this new application. Are people loving it? Do they still grumble?

What's the community response been like from people, maybe like myself, who likes Windows but doesn't go back historically because of the terminal? Or people who have just been Windows users the whole time and kind of quietly despised the old command prompt. Are they happy about it? Yeah, so the overall sentiment has been pretty positive. I get a lot of tweets saying, like,

thank you so much for your work on this. I can finally use it because X feature came in at whatever release point. So I feel like with every release we open it up we open terminal up to a wider audience because we're relieving those pain points of what's missing and there's still a ton of stuff missing like we know that and that's you know why we're still we still have jobs because it's still under development but i think with the 1.0 it was really big because it was officially like a stable app that we knew would likely not crash on you, which is important, especially if you're doing command line stuff. You really got to make sure that's a stable application. So that was kind of big because then enterprises can go in and get it and rely on it as a daily driver. So that was where the 1.0 was really big. But with every incremental release,

when we add new stuff, it unblocks a subset of people. So every month it gets a little bit better. And we still get responses of like, I can't use this because X feature's not there. And it's on our roadmap and we're working towards it. So that's kind of nice for us to know. We will get there eventually and it will be

something that you can use. So it's, since it's still, it's such a new product and we only have about five developers on the team. So it's a really small team and we're just working as fast as we can. What are the major blockers for folks? Like if you had a short list of things that you are obviously not there yet that gets requested all the time. Yeah. So settings UI is a big one. A lot of people don't want to open a JSON file, which is valid. Also opening administrator tabs next to non administrator tabs. That's another big one or run the terminal as another user. That's a big one as well. A big one that we unblocked was the right click open in Windows Terminal, Windows integration, where you could right click on a folder in File Explorer and it

would show up. That was a big one that a lot of people were asking for. I know Quake Mode is another big one where you would hit a hotkey and then the terminal would open at the top of the screen. You could do something really quick and then you could toss it away. So it away so we are making i thought you said quake mode like the video game yeah that's where it comes from is that what it's called oh it's like a hud it's like a drop yeah yep yep okay i retconned your word i thought you said quick mode i was like she surely didn't say quake and i was like oh she said quick and now i'm both wrong and stupid. Please continue. We're working towards quake mode now in terms of ways to run your terminal. So in 1.2, we have focus mode,

which is removing the chrome of terminal. So it's really just the box. It's just the text box. There's no tabs. Everything I worked on is gone, essentially, all the UI. And it sits- How rude. I know. It sits on top of any window. So that's a stepping stone towards quake mode,

because then when you launch Terminal, maybe you don't want all the tabs and stuff, and you want it to appear on the top of all of your windows. So that's like one step that we were making towards that. I'm trying to think of other like big things that are missing. A lot of pane stuff, like when you can split terminal into multiple different panes in a tab, resizing those with the mouse, you can't do yet, but that's another one. Okay. Trying to think of what else. These are things that like we're actively working on. So these are top of mind. That's a pretty good list. Oh, and default terminal is a big one.

If I type cmd, I want it to launch in terminal. That's a really big one as well. So what is the executable? Is it terminal.exe, or how do you launch it directly? Wt.exe, so Windows Terminal. Okay. Couldn't you just alias that in your own machine? Not you, Kayla, but whoever wants that feature, couldn't you just alias that in your own machine not you kayla but whoever wants that feature couldn't they just alias yes we have command line arguments or a shortcut so

you could do like wt and then do like split pane or new tab and profile name and all that stuff so you could launch terminal in a specific configuration and pin that command alias as like something in your taskbar or something on your desktop. So when you double click on it, it launches terminal in that config, which is really nice. A lot of people are in the habit of typing PowerShell or typing CMD. And then that's where the pain comes in of it's launching. My traditional workflow is not compatible with terminal yet because I'd have to change what I look for or like, I don't know. Gotcha. Or if they have automated things that launch CMD or something and they want it in terminal, then that's where things get like dicey.

Yeah. So it's still in a world where it's like several ways in, several ways out of Windows Terminal or typical path that developers are using. Yes, I think I understand your question. Meaning that there's certain flows that are just launching the command prompt directly versus Windows Terminal because it had never been there before. Right, right, exactly. Yeah, so it's just kind of integrating it better into people's workflows because our goal is not to change what people do for us.

We would like to change to be useful for them. That's the goal. It's just like I'm blocking those types of things are like the top requested features. Well, speaking of developer-focused features, nice to see you've got GIF and image in the background text window support. These are the things that really matter. When we were on Cal State, we wanted it to look tight. And you guys definitely addressed that particular need. Yeah, so the background image support

was actually done by a community member on GitHub. We've been focusing on, like, let's make this thing usable, you know, get it working, and then add the cool stuff on top. But someone wrote all the code for GIF support and image support in the background. And we're like, okay, sweet. So we just added that in. So that's kind of where that came from. So to me, all the cool stuff comes from the community, like the retro terminal effects, where you can get scan lines and have the text glow. So it looks like an old CRT display. That was from a community member. Like we didn't do that.

But the code was so good that we had to put it in. So that's why that's there. So yeah. And then like tab reordering, that was a community member too. I remember we were at Ignite and he did it on the booth, like on the show floor. He coded that, the tab reordering. Wow. And then he came over and showed it to us.

And we were like, this is so cool. Like, please make a PR. When that happens, that's when you just offer the guy a job right there on the spot. Don't you? You're like, wow. He works for Microsoft,

just not on, not on our team. We'll steal him from his team. Are you looking to switch teams? Yeah. So, yeah. So all the cool stuff comes from not us.

That's, that's where my mind's at. Um, although terminal is very cool. So, yeah. And stuff comes from not us. That's where my mind's at. Although Terminal is very cool. And you make it all possible. None of this cool stuff could be cool if it weren't for the base Terminal. Yeah, that's true. Which is something to mention too, the fact that this has been open source since the beginning.

We kind of glossed over the fact, sure, you had an announcement, and this is new, and it's replacing. It's the new experience, but it's also been open source. And so I'm assuming that based upon you looking to VS Code and things happening there, that there's a lot of things happening around Microsoft tooling that is open source and there's a lot of fruit from that. And you're kind of describing at least one of them now, which is community contributions. Yeah.

So I personally see a huge shift towards open source inside Microsoft. A lot of teams have come to us saying like, oh, we want to open source X thing, or we're creating this new project and we want it to be open source. How did you do it? What are the good things that come from it? What are the best practices that you recommend? All this stuff.

And it's cool because I guess we open sourced, I believe we open sourced the first piece of Windows ever, which was the bit that shows the text in command, like console, the con host chunk that was always shipped in Windows and we open sourced it. So it's kind of cool how we've had such an impact. And a lot of the stuff that, a lot of the benefits we get are finding bugs right away.

Like everyone who's who files issues are basically testers for us, which is awesome because, it's very difficult for us to test that if we don't have a German keyboard or we don't typically type in Japanese or something. So they are able to find those types of issues and file them and then we can go hunt them down and fix them. But we wouldn't have found them on our own because we don't have those types of resources. So it's just kind of, that's kind of cool in terms of we have thousands of just testers, which is awesome because it benefits everybody when we fix all those bugs. And then also the like feature request priority list, like our priorities come from GitHub and that's because people are commenting on issues or filing new issues. And we interact with the community every day. Like only work in github none of

our code is anywhere else and like we have our developers go through the same process that any other community member would go through in terms of submitting code so we try to make it as even of a playing field as possible between like us and a community member so it feels welcoming and then we get those really good contributions like the background images and the retro terminal effect. I love that one. It's so cool. That is cool. It's really a community, which is really awesome. And it only can benefit, in my opinion,

like provide benefit to the terminal because you're having people read the specs that you're writing or help you think of use cases maybe you didn't think of. And it's just more, it's just like a really big team is kind of what it boils down to, which is really cool. And I really started to pay attention more closely to VS Code even whenever I saw more Go developers using it. Bill County in particular, there was particular Go support in VS Code.

And it was like, that was like a turning point. So it makes sense to kind of treat the same thing here with Terminal that when you get more community members to make it their own and solve their own needs or just be more fun to use, you know, like put some of your own personal flair into it or desires into it when it comes to making it fun to use, it would make sense that it becomes more of a staple for developers to use rather than thinking, well, there's only the command prompt,

there's nothing else out there, and they can now begin to adopt Windows Terminal for their day-to-day driver. Yeah, and then make it their own, too, with all of our customizations and stuff. So yeah, we hope it is a fun thing to use and helps benefit people's workflows. Plus, once it goes into Windows proper, into the stable OS release,

I mean, just having a little bit of your code inside the OS or shipping alongside Windows updates, how cool would that be? From somebody who doesn't work there, just a user of Windows, writing some code that I assume if terminal is optionally a default, that you're going to actually ship the terminal app alongside the operating system, right? So we're still working on the implementation of that. Another proposal that we have is shipping like a stub package. So then when you click on it for the first time, it will go install terminal from the store and then make it the default. So it wouldn't necessarily ship inside Windows. But if you do make any changes to the conhost bit of our repo, which is the stuff that's in original CMD, then your stuff

goes back into Windows and ships regularly. So there is still opportunity to write code for Windows. Okay, you saved it it but it's the conhost stuff rather than terminal but that stuff hasn't been touched for 30 or 40 years yeah so we update conhost for bug fixing and then if there's anything that can benefit um terminal that could also benefit cmd or powershell or the original the inbox experience like we're we're working on a lot of performance improvements right now and that stuff will go back into Windows too. It's not necessarily new features,

it's more like maintenance and performance improvements. Speaking of that, I found a funny bit in your readme which I thought I'd bring up because it made me chuckle. New contributor onboarding is a huge part of open source and a lot of times people run into things that you just weren't expecting they'd run into. I'm assuming this has been run into plenty of times because you have an FAQ.

Only there's one item in the FAQ. It's really just a frequently asked question itself, which is people apparently are downloading the project, they're building it, and they're running it, and they're saying, this looks just like the old one. This is terrible. This hasn't been touched for 30 or 40 years.

And it turns out both code bases are in the same Visual Studio project, right? And people are accidentally launching the wrong one or building the wrong one. Yeah. And getting all sorts of confused. Yeah. So when we first announced a big issue that was being filed multiple times per day was it still looks like the original. And because people would build it and then assume if I ran CMD, it would launch in it. And that's not the case.

So we put that there a long time ago. And I guess we just haven't taken it out. And that's not the case. So we put that there long time ago, and I guess we just haven't taken it out. I guess it's still useful because we don't get that issue filed anymore. But it was just kind of funny how we're like, no, you have to launch Windows Terminal. It was just an education thing. But yeah, there's some funny stuff in our repo. Some of our commit messages are really funny, or responses on some of our like commit messages are really funny um or like responses on like some of our comments are really funny our the release notes are pretty good dustin howitt he's our developer lead he writes our release notes and they can they can be pretty comedic too so yeah we try to have fun on there we try to make it a welcoming community just because like

we're normal people too like we're all just you know trying to make a good product so we just try to keep it fun. How much time does your team spend building and maintaining internal tooling? I'm talking about those behind the scenes apps, the ones no one else sees the S3 uploader you built last year for the marketing team. That quick Firebase admin panel that lets you monitor key KPIs. Maybe even the tool your data science team hacked together so they could provide custom ad spend analytics. Now these are tools you need so you build them.

And that makes sense. But the question is, could you have built them in less time, with less effort, and less overhead and maintenance required? And the answer to that question is, yes. That's where Retool comes in. Rohan Chopra, Engineering Director at DoorDash, has this to say about Retool. Quote, The tools we've been able to quickly build with Retool have allowed us to empower and scale our local operators, all while reducing the dependency on engineering. End quote. Now, the internal tooling process at DoorDash was bogged down with manual data entry,

missed handoffs, and long turnaround times. And after integrating Retool, DoorDash was able to cut the engineering time required to build tools by a factor of 10x and eliminate the error-prone manual processes that plagued their workflows. They were able to empower backend engineers who wouldn't otherwise be able to build frontends from scratch. And these engineers were able to build fully functional apps in Retool in hours, not days or weeks. Your next step is to try it free at retool.com slash changelog. Again, retool.com slash changelog. So maybe you can help us out with some terminology here. This is something that Adam and I struggle with a lot, which is terminal shell command line. All these terms,

these are interrelated things. So a little context on change log news, we have topics and we're also covering things that you run in the command line context and wrote shell tools terminal tools we have a topic for each of these and it's always a a game of chance to pick the right one is this a terminal is this a shell kayla can you help us do you do you know these terms inside and out i'm hoping so maybe you don't i don't know them well. What's the difference between a shell and a terminal? Or a terminal and a command line? Or a console, in the case of the old conhost?

Do you know these terms? Yes. Can you help us understand them? Yes. So this was explained to me on repeat for the first three months of my job. Because I didn't know. Okay. And what's really awesome is that people from the Windows community have it backwards from people in the Linux community. Oh, fun. So there never really

is a great answer to solidify like what it is, but the way that we use it is that the terminal is the UI or the thing that you interact with that appears on the screen. And then the shell is what's running in the back end. So for us, we would say like command prompt is the shell or PowerShell is the shell or Ubuntu. And then it's running in a terminal. So like terminal emulator. So that could be like Commander or Windows Terminal or any of those. And then console, we use it as the same thing to mean as like a terminal. So it's the UI on top. But we just say console because it helps differentiate between the inbox Windows version compared to like the Windows Terminal.

Okay. So the console should also be the ui in the front but it is confusing for sure but that's how we split it up so whenever i say shell i'm referring to like command prompt or power shell and then terminal would be terminal or console would be the thing that renders the text on the front end so the shell only is able to receive data and send it, and then it interprets it and then sends it back out, but it doesn't know what it's getting. Or sorry, this is definitely difficult to explain.

The terminal in the front only receives and inputs data. So it doesn't know what's happening. If you type like LS, the terminal is just sending L and S to the shell and it doesn't know what's happening. And the shell interprets LS and is like, okay, list the stuff in your directory and then outputs that text.

And then the terminal's like, oh, I have output, let me display it. So the terminal has no clue what's happening in the shell behind it. It's just only there to display the info. And the shell is the one that's processing it in the backend and knows what to do with that information. So that's kind of how that differentiates. But I'm pretty sure if you're on Linux, it's backwards. Or if you're on Windows, it's backwards. One of them, it's not the same. Depends on which way you're looking at it. Yeah. Which OS you think

is backwards. Yeah. So what about a command line? Is that just another word for the interface? And that I would say that would be like command prompt too, because that might mean you're at the prompt. You're where you would enter text similar and commit to command line, for example. Yeah. I would interpret that as whatever executable you're running in the shell. So you could run something.exe and that's your command line. So command prompt is how I would interpret command line as well. But you could also do commands as part of the command line, like ls or dir or any of those. Right, individual commands. I think that's more of a stretch, but that could also be

something. I guess that's more of a command rather than the command line now i'm just talking in circles but that's how you end up yeah i've done this before and that's how it happens right there that's how people get confused if you're confused listen to this then hey adam i have talked circles around this during the party yeah and some people will say that i'm completely backwards and completely wrong so it really just depends depends on what your background is. So you're probably fine on what your layout is on changelog because it probably makes sense to some people. I don't know. That's our problem is we have so many options.

Well, the problem is we're not internally consistent, even between the two of us or even between myself last week and myself now. I'm like, before I used terminal but this is more of a command line so if listeners out there if you have a resource like the canonical place that defines these terms

or if you agree with Kayla or you want to explain it for yourself holler at us we'd love to hear what the listeners think on that particular subject it's a tough one definitely well hard rotation away from difficult jargon

onto a topic that we've been talking about. Man, Adam, is this becoming the font show? It might be. The font 2.0 show. Kayla also runs the Cascadia Code Project at Microsoft, which, just like Fear Code, is a ligatures font. So tell us about Cascadia. Yeah. So when we were designing Terminal and we had the idea of the new Terminal, we wanted

it to feel like a new, fresh experience. We wanted this to be like, this is what's new on Windows. This is the new command line thing. And when we were working with our UI of the tab strip and all of that, it still didn't look new and fresh because the font that we were using was Consolus, which is the font that's been around for 20, 30 years. And it's funny because the largest real estate on the screen of Terminal is the text. That's the thing that takes up the most amount of screen space is the text. So we figured we're going to need a new font if we want this to look new. So then that's kind of where the effort came from of why are we making a new font and how is it related to Terminal?

That's kind of where Cascadia code originated from. And then we previewed it at build and we just called it Cascadia code because we were thinking of what to name it. And Cascadia is the code name that we used for terminal inside Microsoft. So before we named Windows terminal, it was called project Cascadia. And there's still some references to that in our GitHub. Some of our folders and code packages and stuff are called Cascadia. So that's where it came from. So it's an homage to Terminal. And then the code part is to help indicate that there are programming ligatures inside. So like Fira code or Cascadia code, those both have ligatures. So that's where the name came from and like why it was made.

So we worked with a font designer and finalized the name after build because then people saw it and then started calling it Cascadia Code and were like, well, we can't change it now because now everyone knows what we've just been calling it internally. So we finalized that name and then launched both a ligature version and a mono version. So Cascadia Mono that doesn't have ligatures. So yeah, I'll keep going on how we released. After that, we added Powerline glyphss so you can use it with powerline and a bunch of like box drawing glyphs so you can have more of your stuff displayed and then we added the latin one character set after that which was a bunch of like latin-based

languages and then the latest thing we added last month in June was font weights. So now you can have bold or thin or semi light or light or any of those, which has been heavily requested because the font itself is a heavier font. Like I personally like semi light, which is like one step below normal because the normal is pretty thick anyway so that was the latest thing that we added but what was interesting is we we wanted this to be the default in terminal because we wanted the experience to be fresh like we wanted to be new we didn't want console list to be the default so we ship we actually ship cascadia code and Cascadia Mono inside the Windows Terminal package and then set Cascadia Mono as the default font. So you can switch between them if you want to turn ligatures on and off. You don't have to go install something new.

It's already included in the terminal package, which is really great. But if you want the Powerline glyphs, that's a separate font. So that's on GitHub. We have a GitHub repository for Cascadia code as well. So that's how we ship. And then a funny thing that happened is the second we made Cascadia code the default, there was an uproar on Twitter because we turned on coding ligatures for everybody. And we didn't even think about it.

My daily workflow is GitHub or Git in the command line. I write code and then use Git to push it up to GitHub, so that's what I use Terminal for. So ligatures never really appeared on my screen, so I didn't really think much about it, but then there was this whole thing of, this is not accessible. Ligatures are technically not accessible,

and we needed to make sure that Windows Terminal was accessible. So we very quickly, either the same day or the next day, shipped a servicing update that changed the default to Cascadia Mono, which doesn't have the code in ligatures. And that's why both are shipped in the package because we did a flip and then some people are relying on Cascadia code now and we can't just take that away because then it'll go back to Consolus after that. So that was just a funny thing that happened and it wasn't even something that we thought about because we were just so used to it.

But this is why it's so great to have this community because it's like, no, no, no, no, no. Back up. We're like, oh, okay, sorry, sorry. So we just fixed it. And then that's also what's nice about having a really quick release cycle is that we could ship updates within a few hours, which is kind of nice.

Yeah, quick fix to a problem that you didn't foresee, but that was immediately obvious as soon as people started using it, right? Yeah, it was a really good learning experience, and it wasn't even something that we thought of. But it's great that it was brought up so quickly. And I think it was brought up the day we shipped that update or the day after. And they were like, no,

no, no, no, no, no, no, no, no,

no, no, no, no, no, no, no, no,

no, no, no, no, no, no, no, no,

no, no, no, no, no, no, no, no,

no, no, no, no, no, no, no, no,

no, no, no, no, no, no, no, no,

no, no, no, no, no, no, no, no,

no, no, no, no, no, no, no, no,

no, no, no, no, no, no, no, no,

no, no, no, no, no, no, no, no,

no, no, no, no, no, no, no, no,

no, no, no, no, no, no, no, no, no, no got mono and code,

so the code actually meant the ligatures. So thank you, Kayla, for finally drilling that home for me. I didn't quite grok that, that you got the code and the mono. So Cascadia Mono is simply just for monospace font, while code has the code ligatures. That totally makes sense now. And three shows later, finally getting it. So clearly I'm dense.

Welcome to the party. There you go. To the code party. go the code party i mean i get i mean it would make sense i just i guess i would just think you just ship it all and you get the code ligatures for free so i don't know i just i guess to turn them off you'd need the monospace version sans code ligatures yeah that's right but you couldn't call it cascadia sans that's a a whole other thing, right? Oh, yeah. It would look like Comic Sans, which is not something we'd want. That's how most of my code should probably be, in Comic Sans, honestly. And speaking of, these past shows we've done, we've talked with Nikita on Fear of Code.

In your special thanks in your doc, you've got a thank you to that project in terms of the coding ligatures. So awesome there. So are you using their ligatures then? Are you pulling them in to Cascadia? That is a great question. Or do you know what the thank you is for? Just for the inspiration? Yeah, I think either we pull from them or it's a thank you to them. Our font designer set it up and we did it so long ago. I honestly don't quite remember how that happened.

I want to say, because they're open source as well, I want to say that we ingested those, but I am not entirely sure. Okay. That was so long ago. It's all good. They either directly inspired or directly contributed in a way. It's the spirit of open source. Yeah.

Yeah. Well, I think what it does for sure while we're talking about it again is that it's clearly one an aspect of the interface that we need to pay attention to two can have as we have just said through my uh silliness is that you can have a coding literature version of it which is super cool that's the point of it to sort of enhance the experience as a developer to get special features from the font, font face in your interface. But just how important this thing is, this type of like the font that you use, how important that is to developers. So, I mean, even rewinding back, that's a big part of what you were trying to do with Windows Terminal is not just give it a facelift and new features, but like kind of evolve the interface.

And a big part of that is 100% the font. Yeah. The choice of it. Yeah, definitely. Don't mind me. I'm just over here just trolling through Cascadia code on GitHub trying to find out, are they actually using their ligatures? It says thanks for the Fira code, open type code for the coding ligatures,

which makes me think maybe you're using the same system that he uses in order to generate the ligatures, but maybe it just means for the ligatures themselves. Well, this begs to be some sort of standardization across different font faces, different typography, in this case Cascadia or in the other case Fira, that you can have sort of like that open type code, as you just said, Jared, to enable, you know, hey, you want this style of font? Great. It can have these ways to have the coding literatures.

It's like unsolved mysteries for open source. In our world, we can just go ask Aaron Bell and he'll tell us exactly the truth. He'll solve the mystery real fast. Yeah, he would definitely know. Yeah, he's our font designer, so he would definitely exactly the truth. He'll solve the mystery real fast. Yeah. He would definitely know he's yeah. He's our font designer. So he would definitely have the answer. And a fantastic one shot.

The Aaron Bell at Aaron Bell on Twitter, if you want to hit him up, but definitely type design and typography is, is what he does. That's awesome. So Kayla, we know the settings UI is coming down the pipeline and you have a list of things that are in the works.

Anything else folks need to know about? Like what's the best way to play with terminal, get on the preview train or the official train? What's the touch points for folks who would like to try this out or maybe contribute a feature or just follow along and watch as it gets better and better? Yeah. So there's a few different resources that we have. So you can download the preview or just plain Windows Terminal from the Microsoft Store. And if you don't have access to the Microsoft Store, we also publish those builds on GitHub

under the releases tab. So if you can't get the Microsoft Store on your machine, you can get it that way. You would just have to update manually if you wanted the latest updates. You'll have to update manually if you get it from GitHub, whereas the store should handle it for you and give you those updates automatically. The difference between the two is in preview, that's where we ship the latest features first. And then a month after they've been in preview, we move them over to Windows Terminal

proper. So that way all the bugs have been ironed out and it's been tested and all that. And then you'll get the new stuff. So if you're someone who wants the newest features as soon as they come out, you don't care if it's a little buggy, you can go on the preview branch. Or if you really care about stability, then you can get on the Windows Terminal branch and you should get the new stuff a month after we announce them. So it just depends on what your needs are and what your preferences are in terms of getting the new stuff. But all the newest stuff will be in preview first and then migrate over to stable. And then in terms of knowing what's going on, we have a blog and that's at devblogs.microsoft.com slash command line.

And I write a blog post for every release that we have. So if you are curious about what new features have made it into preview and then migrate into stable, I iterate through the big features on there and explain how they work and how to get them working or like what's new and all that stuff. And then also I'll tweet random terminal things that are happening, or sometimes I'll do a poll if we're figuring out like a default setting, I'll do that on my Twitter. So that's a really good place to go to as well. And then in terms of providing feedback and doing feature requests and issues and stuff, the feedback link that's in Windows Terminal, so in the dropdown at the bottom, I believe it says

feedback, that will take you directly to GitHub. So if you don't know how to get there, that's one way to do it. Or you could just, I'm sure you could just Google Windows Terminal and the GitHub should show up very quickly. But you can, if you see a bug, we highly encourage you to file it. Or if you are like, man, I wish I could do this, please, please file a feature request because that's how we operate, through GitHub. So that's how contributions can happen. And then also, if you want to comment on specs that are being written and provide your opinion, or if you want to look at some PRs that are in progress and try to contribute there, you can comment on those. We do value like comments and issue filing,

like in creation of PRs, we, everything counts and we truly value all of that. So those are some ways that you can contribute to. Very cool. We'll drop some link in the show notes for the listeners to follow along. That way they can take suit as you mentioned there. And Kayla, thank you so much for your time. It's been awesome. Yeah, thanks for having me.

Alright, give it up for Kayla and all the awesome work they're doing on Windows Terminal and making that a great experience. And by the way, I have some semi secret news to share. We're beta testing a membership that lets you, yes yes you get closer to the middle it's called changelog plus plus and this is the first time we're mentioning it publicly support our work help us test this program and make the ads disappear at changelog.com slash plus plus one of the cool things is we've slashed our rates for

early adopters like you so go check it out again changelog.com slash plus plus. One of the cool things is we've slashed our rates for early adopters like you. So go check it out. Again, changelog.com slash plus plus. And of course, huge thanks to our partners who get it, Linode, Fastly, and Rollbar. Also, huge thanks to Breakmaster Cylinder for making all of our awesome beats. Thanks again for tuning in this week. We'll see you next week. Thank you. Bye.