Terminal: [Feature Request] Border-/Titleless windows for displaying dynamic information with the Terminal

Created on 4 Aug 2019  路  23Comments  路  Source: microsoft/terminal

Description of the new feature/enhancement

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.

screenshot

Proposed technical implementation details (optional)

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.

Quick Note

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.

Area-User Interface Help Wanted Issue-Feature Product-Terminal Resolution-Fix-Committed

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:

  1. Add the ability to hide the titlebar/tab row
  2. Add the ability to drag the window when the tab row is collapsed
  3. Add the ability to keep the window on top of the z-order

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:

  1. Add a keybinding/action to toggle the titlebar's visibility
  2. Auto-hide the titlebar when the app loses focus.

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."?

All 23 comments

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:

  1. Add the ability to hide the titlebar/tab row
  2. Add the ability to drag the window when the tab row is collapsed
  3. Add the ability to keep the window on top of the z-order

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:

  1. Add a keybinding/action to toggle the titlebar's visibility
  2. Auto-hide the titlebar when the app loses focus.

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.

Concept

borderless-term-concept

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

  • Add the ability to hide a) the empty (above and to the right of tabs) part of the tab row and b) the tab control elements (add new tab, the expandable menu button), but leave the tabs intact (it's fine to have an additional option to get rid of the tabs themselves, I just don't want it to be the only way to configure the tab row)
  • Make this optional: add the ability to drag the window when the tab row is collapsed. I already have a great way to drag the window and don't need anything extra
  • Makse this a config item: Add a keybinding/action to toggle the titlebar's visibility. I can do it with an keybind already

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:

  • Add a keybinding like toggleFullscreen called toggleBorderlessMode (or something), and plumb that through all the layers like toggle fullscreen currently does.
  • Fullscreen mode already hides the tab row, so do basically that when we enter borderless mode.

    • I'm pretty sure the logic for fullscreen already uses something like "is the titlebar visible", not "is the window fullscreen", so most of it _should just work_.

  • Do an enormous amount of testing

    • Check what happens when we enter borderless mode from maximized

    • Check what happens when we enter borderless mode from fullscreen

    • Check what happens when we enter fullscreen mode from a borderless window

    • Check what happens when we win+arrow snap the window while it's borderless

    • etc.

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:

So 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.

  • ShortcutActionDispatch.idl - This is the file where you'll define the ShortcutAction, which we can use to trigger the "toggle borderless" event.
  • ShortcutActionDispatch.cpp- This is the file where you'll make sure to raise the "toggle borderless" event in response to the ShortcutAction we defined earlier.
  • AppActionHandlers.cpp - This is where the Terminal handles all it's keyboard shortcuts. See in this file how the ToggleFullscreen event is implemented. See also:
  • TerminalPage.cpp - This is where the Terminal

    • marks itself into fullscreen mode

    • updates the appearance of the tab row to be hidden

    • raises an event that the Win32 layer will need to handle, to redraw the non-client area.

  • This is where we update the visibility of the tab row
  • You'll need to define a new event like ToggleFullscreen on TerminalPage, and bubble it up through AppLogic.
  • Once the event is bubbled from TerminalPage, through AppLogic, it'll need to be handled in AppHost.cpp, which should call a new method similar to ToggleFullscreen on NonClientIslandWindow
  • Update the logic in _GetTopBorderHeight in NonClientIslandWindow.cpp to also account for borderless mode
  • Probably update the logic in _IsTitlebarVisible, and anywhere else _fullscreen is used in NonClientIslandWindow

i 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.

Don't get me wrong much love for trying to help me and others out here and windows is moving in a gr8 direction lately.

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:

Was this page helpful?
0 / 5 - 0 ratings