Hide Window Borders

[mehcode]

Is there a way to hide the window borders without maximizing?

[gnunn1]

No and in general no plans to do this. However if you find the window borders are larger then they are for other apps, particularly Gnome terminal, post some screenshots along with info about which distribution and theme you are using and I'm to happy to have a look.

[mehcode]

@gnunn1 As this project seems to take a lot of ideas from terminator and terminator does have a Hide Window Borders toggle, it'd be nice if we could have that here. It's the one thing I miss coming from there. Everything else is far better.

Would you accept a PR for this?

[off-by-some]

An example of the desired behaviour (terminix/gnome-terminal):

On arch + awesome wm with a basic config

Would love to see this as its basically the only thing that's stopping me from switching from gnome-terminal + dvtm

terminator's "borderless" option also hides the menu (File, Edit, etc) Not really a feature i can't live without, but it would be awesome as well

[gnunn1]

@mehcode Yep, I would accept a PR for this. Obviously it needs to be optional and off by default, the option should be presented in the Appearance section of the General tab in preferences.

[off-by-some]

@mehcode Yep, I would accept a PR for this. Obviously it needs to be optional and off by default, the option should be presented in the Appearance section of the General tab in preferences.

I might recommend also putting all the options you can access via the window bar on the right-click menu too... Wouldn't want to disable it and all of a sudden be unable to access the preferences panel for example

[gnunn1]

@pholey, why wouldn't you be able to access it, accessing preferences is via the gnome App menu and shouldn't be affected I would think? If it is, i would need to re-think accepting a PR for this.

[off-by-some]

Im a bit confused as to what you mean exactly by the Gnome App menu.. From what i can see, the only way to modify your preferences is by actually hitting the terminal icon on the left side of the actual terminix window border:

Since we are talking about removing this entirely via a configurable option, Providing there is no other way to configure your preferences, i would imagine terminix would either need to show/hide the actual menu bar (File, Edit, View, etc) by pressing "alt" (as many other apps do), or by having an option to click in the tooltip menu to allow for further configuration (at least to be able to renable the window border):

[gnunn1]

Sorry, I'm in an airport and should be paying more attention. I'm OK with a PR to make the window borderless, however the headerbar cannot be removed and I won't accept a PR that removes it even optionally.

[off-by-some]

@gnunn1 That is rather unfortunate, as many other terminals have this option (Actually, any terminal/gtk app i've can think of at the moment has the option to disable the toolbar or at least left it up to the actual window manager to decide).. Self managing windows without paying any mind to the actual window manager is rather annoying and even considered bad practice by some

[dsboger-zz]

@pholey you could use fullscreen view?

EDIT: I just re-read the "without maximizing" from the OP.

[gnunn1]

Terminix is targeted at the Gnome environment, while I'm willing to make some accommodation for other environments (looking at you Unity) I have certain boundaries one of which is the headerbar/toolbar. Terminator has the goal of covering a wide range of platforms and environments, frankly I don't and that's OK, there's lots of options out there.

The nice thing though is that if someone wants to fork Terminix and make those changes its easy enough to do.

[off-by-some]

@gnunn1 Gnome doesn't really have anything to do with the window manager however. Depending on your distro, usually gnome will be shipped with openboxwm or something similar. Windows should act the same on xfce, as it does on gnome, kde or even unity providing the same window manager is used. This is why its considered bad to manage/style windows based off of the Desktop environment (i.e gnome in this case) rather than the actual window manager (Because it will just look wonky in another DE).

This is a very easy and non-obtrusive feature to add that would improve visual aesthetics and functionality everywhere that isn't gnome, so i am a bit confused by your reluctance to even accept a PR for it.. Would you mind explaining your reasoning/concerns as to why? You could implement this without really changing the UI at all if that is your concern (just by adding the show/hide menu bar with alt and allowing it to be changed from there in the view tab)

[phw]

@pholey Have you tried setting the hidden disable-csd option for Terminix with dconf? That will enable your WMs native Window decorations. It will still show a toolbar at the top with the important buttons, but the Window management buttons (minify, close etc.) will be gone and maybe this makes it fitting for your use case.

usually gnome will be shipped with openboxwm

Actually Gnome uses Mutter, and AFAIK it is rather hard to replace it with something else as the gnome-shell heavily depends on it. Just nitpicking, sorry

[gnunn1]

@pholey As @phw pointed out, Gnome uses Mutter and it's not common running the Gnome DE on a different window manager. GTK the toolkit obviously runs on a variety of window managers though.

With that out of the way, let me try to answer your question. The first thing to understand, as I mentioned previously, is my primary target audience are people who are using the Gnome DE (i.e. gnome shell). A secondary audience for me are people using GTK 3 based distros within a traditional windowing environment (Unity, Pantheon, Budgie). Definitely not in my target audience are the folks using tiling window managers like i3. A bit of a fuzzy area for me are things like XFCE, KDE, awesome, etc, if terminix works in those environments great, but I'm not planning on actively supporting them.

So within that context I'm struggling with understanding why this use case is needed. As soon as you hide the headerbar the window is no longer drageable by the user AFAIK I can tell with no capability to re-position it. Additionally, no other Gnome app that follows the Gnome HIG does this (gedit, nautilus, etc) AFAIK. Gnome Terminal lets you hide the menubar but not the window titlebar, if at some point it supports CSD I really doubt it would let users optionally hide it.

However, I do have a hidden option to disable the CSD as @phw points out in which case the headerbar becomes a toolbar, so maybe you are thinking in the case where the native window decorations are being used there should be an option to hide the toolbar? (Your screenshot though clearly shows the header bar being used.) That could make a bit more sense to me, so let's take a look at what's involved with implementing it.

I can think of three ways to do this off the top of my head as follows:

1. Simple option to toggle the toolbar invisible and that's it, no changes to UI and none of the toolbar options are available anywhere else. This is simple to implement though you would have to only allow the option to be enabled when the CSD is disabled. It's also a bit craptastic as a solution since options are only accessible via shortcuts which impacts discover-ability. Finally, as you pointed out this hinders accessing options in the gnome app menu, or in your case, where the gnome app menu goes to when not in gnome-shell.
2. Hide the toolbar and move all menu options into the right click context menu. I'm already doing this for the option which hides the terminal titlebar, as you can see in the screenshot below it increases the size of the context menu by quite a bit. Removing the headerbar and trying to squeeze those options here as well would really bloat that menu. Additionally, it's actually building a second UI mode (menu driven mode) that needs to be taken into constant consideration and tested when adding future features.

1. Hide the toolbar but allow it to become visible by using a modifier key (i.e. alt or ctrl). To do this would likely require the use of a new Overlay and Revealer so it's one more UI layer in the app. Additionally, the toolbar revealer potentially conflicts with the sidebar revealer, i.e. which one goes on top when both are shown? Another option to avoid that is to have the toolbar push down the content like the terminal search does, there might be potential issues with GTKPaned widgets though in terms of adjusting and restoring geometry after a hide and show.

To me options 2 and 3 involve a fair amount of work, option 1 is a bit craptastic and not really to my liking, I can already see the bug reports about "How do I access option ...". This in conjunction with the fact that I'm not seeing how this use case is very useful doesn't make me want to invest the effort in implementing the feature and more importantly, supporting it over time.

Hopefully this explains my viewpoint a little more, I'm happy to discuss it more if you have some counter-points.