Bring back tab autohide feature from #832 #833
Conversation
Bring back autohide feature from elementary#832
|
I have tested it from the "horus" branch on my 7.1 installation - appears to work good. Hope it will be added to the next update for 7.1
|
BorisNA
changed the title
|
Does this work for "Always", which means the tabs should be always invisible even when there are more than two tabs? |
|
No, unfortunately it doesn't work for "always" - I looked through the Hdy.TabBar and didn't find option to permanently disable tabs. Possibly we could not use TabBar in this case at all, but it would be rather serious change to the code. P.S. I wonder if we can just remove here add (tab_bar); |
|
What about using the visible property inherited from Gtk.Widget? |
|
I am not against bringing this option back as there was, as far as I recall, any conscious decision to remove it. However, if it is worth having I would like to see it exposed in the UI. Needs input from the @danirabbit. |
This may work, thanks (I have almost no prior experience with Gtk or UI widgets at all). I will definitely look into it What really bothers me is that option "always hide" in this implementation will be mega-confusing. Say, I have enabled always hiding the tab bar and later spawned a tab with command-line key or shortcut. Would that mean that I'll get an invisible tab in the background, or the current tab I'm working with will magically disappear "behind" a new one? And no way to switch or even know that there is something there. Looks like the logic for "always hide" should be something like "hide the tab bar and substitute opening new tab with opening new window".
I'm truly sorry if I misunderstood you and my reply was harsh. When I work on the big monitor, Ok, I can live with a single tab in the tab bar, it just doesn't worth arguing. But for smaller screens it really hurts, I cannot have for example two terminals side by side (vertically) and so on :( And it worked before, on the same OS version. |
I agree. I can understand hiding the tabbar when there is one tab if you need the screen space, but if there are multiple tabs you need some way of knowing where you are. One possibility is some kind of tab-switcher in the headerbar but there would be no space for names. |
Drop-down tab switcher with some custom button in the header bar indeed is a possibility, but this will introduce nonstandard behavior. I believe it will confuse users too and be against main elementary idea (as I get it - simplicity and consistence). Maybe we really can change the 'new tab' behavior with the 'new window'? That is, all accelerators, command line options and so on will just spawn a new window? Each window will have just one tab and have the tabbar hidden. It wil lrequire some painstaking code fixes, since new tab is spawn in different places here and there, but at least will not introduce new concepts for user. |
The simplest and most consistent way is to always show tabs 😉 |
|
Ehrm, I'd disagree. The simplest way is to not use tabs at all and leave window switching for whom it belongs - that is window manager. |
BorisNA
force-pushed
the
tabs-autohide-832
branch
from
becc5a3 to
6ee9be1
Compare
Current implementation works and its behavior replicates that of 6.1.2/6.2.0 Unfortunately visibility settings could not be used (they don't work) since Hdy.TabBar appears to dynamically set it based on the 'autohide' property So the only solution is to not add it to the box
|
I tested the old version (6.1.2/6.2.0) behavior: it really didn't show any bar when the "always hide" option is used, but the user could change tabs with the keyboard shortcuts. So, I replicated this behavior by not adding For now, it works 100% as the previous version and I propose to add it to the codebase as a regression fix. I'm open to discuss new logic I proposed (switching tabs behavior to window behavior for this "Never Show" setting) if the maintainers will approve it. |
|
I can confirm that this works as expected from the code. If someone can confirm this reproduces exactly the behaviour of v6.2.0 and before, I will not block merging even though I dislike many aspects of this behaviour, particularly "Never show tabs" e.g. the options shown in the tab context menu are lost and changes to the settings are not reflected in the UI unless the app is closed and reopened. Also need go-ahead from @danirabbit . |
| add (tab_bar); | ||
| if( tab_bar_behavior != TabBarBehavior.NEVER ) { | ||
| // Looks like we can't use set_visible since its value should be overriden in TabBar | ||
| // so the only solution is not to add the widget to the box itself | ||
| add (tab_bar); | ||
| } |
Bring back autohide feature from #832
Should fix #832
Terminal v 6.2.0 had an option to hide tab bar completely or when there is only one tab is present. All the options could not be re-implemented, but we can re-intorduce hide-when-single