Basically I want (hopefully I am not alone) a mode for the Terminal where it is just a blank canvas.
This would allow me to run a Terminal for informational purposes (for example: htop on WSL, or sampler) to see stuff at a glance.
Since this is the only way this Terminal Window would be used (on a secondary monitor for example), it would be nice to reduce the space it takes up and make it more visually appealing by removing the title bar and window controls.
Linux users can achieve this through their window manager, and I have attached a screenshot of someone's config (it's i3 on Linux) to illustrate what I mean.

Mind you, I have not done Windows App development in ages, and I am not sure wether it is even possible to remove the window controls here (Looking for feedback from the devs!).
If it is though, it could be exposed through a toggle with a customizable keybinding.
I know this is like a super superficial feature, and definitely the last thing that should be implemented once everything else is running smoothly. Just thought I'd document here that I think this should be a thing.
I could see this being an option, to open a single tab as a compact overlay window. Or as it is not strictly a UWP app, an always on top borderless window.
Behavioural issues will need to be worked out. I imagine grabbing anywhere on the window should be able to move it, and it shouldn't accept keyboard input, unless the window has focus.
A focused state will be needed and how the cursor and text selection works when not focused, will need figuring out.
This is actually one of the cooler feature requests I've seen in a while. I really like the idea, though I'm certainly worried about the implementation.
Right now, we can't drag the window with anything that's rendered using XAML. So the entire "Terminal Control" area can't be used to drag the window. If we did add support for this mode, while it was in this mode, the window would be stuck there.
There's a couple points all being laid out so let me see if I got them all:
I'm fairly certain 3 is being tracked with another issue somewhere (though I can't find the dupe ATM). As I mentioned above, 2 might be impossible with our architecture. So lets focus on 1.
I could envision a couple ways this ends up working:
I'm not sure how helpful 2 is (though I'm certainly open to user stories for it). As long as there's an action for toggling the visibility, then the user can always move the terminal to the position they want, then toggle the visibility off, work with the terminal, and then toggle the titlebar back on if they want to move the window again.
Implementing it actually seems _super_ easy, as long as the user is using the "show tabs in titlebar" feature. Might not work with that setting disabled however, so that could use some spec'ing on how we want that to behave. Maybe pop a dialog at them saying "Hiding the titlebar is not supported when not using the "show tabs in titlebar" feature."?
I think point 2 is not as important. Since it is hard to do architecture-wise, it might be better to leave it out for now. Though it certainly would be nice to have!
I originally only thought of point 1, but since @mdtauk brought it up I think it would also be pretty important to have it be always on top. I'll go looking for the dupe in a second and update this comment accordingly. I couldn't find any issue concerning always on top mode...
For the implementation, I think 1 would be the way to go (it would also be nice if this was somehow able to be triggered by a shell command, similar to setting the title).
indow with anything that's rendered using XAML. So the entire "Terminal Control" area can't be used to drag the window. If we did add support for this mode, while it was in this mode, the window would be stuck there.
People who use this function wil use things like Windows Powertoys to move the windows.
I really like the idea of borderless terminal window.
Add the ability to drag the window when the tab row is collapsed
How about something like possibility of dragging window while pressing MMB? Not sure if this would be possible to implement, since
Right now, we can't drag the window with anything that's rendered using XAML. So the entire "Terminal Control" area can't be used to drag the window.
Possibility of interacting with terminal borderless mode would be cool, too.
I - personally - wouldn't really need show tabs on focus feature, since I'm mostly working in tmux enviroment.

tabs on focus are useless. if you're working without the titlebar you know your keyboard shortcuts and whould use ctrl + tab. you'd see what tab you are on and don't need the tabs to be shown.
Since my issue https://github.com/microsoft/terminal/issues/3610 was redirected here I'd add a couple of details
You may also read my issue to see how it's already possible to implement what you're asking for for a single-window (i.e. with only a single tab and "alwaysShowTabs" : false) terminal with some AutoHotkey magic (you can also implement the "always on top" feature with an easily googleable script)
Anny news on this?
annyone know's what needs to be done ?
its useless whit the normal windows ui bloat but i realy need terminal that can acces the neccecairy os layers to make an acrylic window.
When there's news on this thread, we'll make sure to post here 馃槈
This is one of my favorite feature requests, but it's not about to land on this side of 1.0. I've got a good idea of the work that needs to be done:
toggleFullscreen called toggleBorderlessMode (or something), and plumb that through all the layers like toggle fullscreen currently does.I'd happily review a community contribution to add this feature 馃槃
wel i'd have a look if someone tells me where to look but i have never worked on other peoples large projects before.
the way you describe it it sound so eazy to do even i could do it.
maybe we could chat a bit on discord or something.
in dire need of windows terminal to be usable now becouse power-toys doesn't work with apps launched from cmder.
or wil they fix it in winui 3?
maybe we could chat a bit on discord or something.
I'd prefer to just leave the conversation here in the open, so everyone could learn from the questions and answers 鈽猴笍
I'd take a look at all the following places:
_fullscreen is usedSo i'm unable to build.
(haven't changed anny code yet.)
firs error is
Severity Code Description Project File Line Suppression State
Error C1083 Cannot open include file: 'wil/Common.h': No such file or directory TextServicesFramework C:\Users\nicta\Documents\dev\VS\terminal\src\inc\LibraryIncludes.h 52
i tried running
Install-Package Microsoft.Windows.ImplementationLibrary
in ps.
this diden't fix the issue.
the next error i have no idea why it whould happen.
Severity Code Description Project File Line Suppression State
Error LNK1181 cannot open input file 'C:\Users\nicta\Documents\dev\VS\terminal\bin\x64\Debug\ConTypes.lib' TerminalApp C:\Users\nicta\Documents\dev\VS\terminal\src\cascadia\TerminalApp\LINK 1
@NicTanghe Please make sure to read the README. You need to restore the git submodules.
Si i'm trying to add a Toggle borderless shortcut action.
but i get the error
enum "winrt::TerminalApp::ShortcutAction" has no member "ToggleBorderless"
but it doesn't point me to where i could ad one.
I'd take a look at all the following places:
Do i set
CoreApplicationViewTitleBar.ExtendViewIntoTitleBar property to true (or is _ToggleBorderless)
in TerminalPage.cpp or TerminalControl.xaml.cs or in another file ?
and does it mattter where in the file i do this.
or do i have to use this.
using Windows.ApplicationModel.Core;
// Hide default title bar.
var coreTitleBar = CoreApplication.GetCurrentView().TitleBar;
coreTitleBar.ExtendViewIntoTitleBar = true;
ps. is there annyway i can just search for all occurences of using Windows.ApplicationModel.Core;in all files ? in visual studio.
PLZ assist or tel me ur not going to and then i'l spend my time more productive.
Don't bother at all with the CoreApplicationViewTitleBar or CoreApplication APIs. We're not a traditional UWP application, we're a modern Win32+XAML app, so the CoreApplication things don't realy apply to us.
I thought I gave a pretty good map of how to add this feature. Let me elaborate more.
ShortcutAction we defined earlier.ToggleFullscreen event is implemented. See also:ToggleFullscreen on TerminalPage, and bubble it up through AppLogic. TerminalPage, through AppLogic, it'll need to be handled in AppHost.cpp, which should call a new method similar to ToggleFullscreen on NonClientIslandWindow_GetTopBorderHeight in NonClientIslandWindow.cpp to also account for borderless mode_IsTitlebarVisible, and anywhere else _fullscreen is used in NonClientIslandWindowi already knew evrything u said.
in NonClientIslandWindow.cpp
When i change !_titlebar to _titlebar at line 705.
Exception thrown at 0x00007FF622CA9027 in WindowsTerminal.exe: 0xC0000005: Access violation reading location 0x0000000000000000.
when i allow tell vscode to not break with terminal it just throws
Unhandled exception at 0x00007FF622CA9027 in WindowsTerminal.exe: 0xC000041D: An unhandled exception was encountered during a user callback. (in windows.UI.xaml.comtrolls.h)
for what i can understand at
RECT rcRest = ps.rcPaint;
rcRest.top = topBorderHeight;
const auto backgroundBrush = _titlebar.Background();
const auto backgroundSolidBrush = backgroundBrush.as<Media::SolidColorBrush>();
const auto backgroundColor = backgroundSolidBrush.Color();
what happens is they paint the a backgroundcolor over the titlebar and then somewhere else they paint a menu over that.
causing me to think hiding the titlebar is impossible becouse it is stil there and having the console window itself start at the verry top wil cause the titlebar to stil be visable beneath the frostedglass effect ......
if this is indeed the case for all apps using the same windows libs u are using then this can't be solved from community input and someone working at windows needs to go tell people that its a better idea to have to turn the default titlebar on with a function then to try and hide it with a function or turn it of with a function.
i know for a fact some non uwp apps dont have a titlebar and are translucant. (cmder). so i am missing something.
In my understanding fullschreen is just a different mode and it doesn't have this problem because it doesn't have the fugly default windows titlebar.
new test at NonClientIslandWindow.cpp
(Reading about this _GetTopBorderHeight() is only able to make the titlebar larger.)
int NonClientIslandWindow::_GetTopBorderHeight() const noexcept
{
if (_isMaximized || _fullscreen)
{
// no border when maximized
return 0;
}
return topBorderVisibleHeight;
}
into.
int NonClientIslandWindow::_GetTopBorderHeight() const noexcept
{
// no border when maximized
return 0;
}
nothing changes in the build.
if i change it to
int NonClientIslandWindow::_GetTopBorderHeight() const noexcept
{
{
// no border when maximized
return 0;
}
return topBorderVisibleHeight;
}
or just
{
return 0;
return topBorderVisibleHeight;
}
i get an error/warning on line 266 (the return return topBorderVisibleHeight; line)
the following warning is treated as an error and unreachable code
i`m back from linux and i wil resume this effort when winui3 is released becouse i think it wil fix this issue.
Cool seeing this come to light, the solution you guys came up with looks terrific. Thanks for making this happen!
My request to remove, among other things, window resize box (https://github.com/microsoft/terminal/issues/3610) was closed as a duplicate of this issue, and now this issue is closed with a PR that accomplishes some of the unneeded window elements, but doesn't actually remove those resize borders ("The edges of the window are draggable to resize, but the window can't be moved in borderless mode." https://github.com/microsoft/terminal/pull/6804)
So it appears that at the moment this part of the feature request seems to be lost in the issue tracker
@zadjii-msft would you then please reopen my old request (or maybe there is some other request that I haven't found) so that it's reflected in the tracker that the borderless mode is not fully impemented yet?
Thank you!
:tada:This issue was addressed in #6804, which has now been successfully released as Windows Terminal Preview v1.2.2022.0.:tada:
Handy links:
Most helpful comment
This is actually one of the cooler feature requests I've seen in a while. I really like the idea, though I'm certainly worried about the implementation.
Right now, we can't drag the window with anything that's rendered using XAML. So the entire "Terminal Control" area can't be used to drag the window. If we did add support for this mode, while it was in this mode, the window would be stuck there.
There's a couple points all being laid out so let me see if I got them all:
I'm fairly certain 3 is being tracked with another issue somewhere (though I can't find the dupe ATM). As I mentioned above, 2 might be impossible with our architecture. So lets focus on 1.
I could envision a couple ways this ends up working:
I'm not sure how helpful 2 is (though I'm certainly open to user stories for it). As long as there's an action for toggling the visibility, then the user can always move the terminal to the position they want, then toggle the visibility off, work with the terminal, and then toggle the titlebar back on if they want to move the window again.
Implementing it actually seems _super_ easy, as long as the user is using the "show tabs in titlebar" feature. Might not work with that setting disabled however, so that could use some spec'ing on how we want that to behave. Maybe pop a dialog at them saying "Hiding the titlebar is not supported when not using the "show tabs in titlebar" feature."?