(In reply to mrmcq2u from comment #0)
> It would be great if gnome-terminal defaults to showing the tab bar when no
> tabs are open

There's a hidden dconf setting for this ("tab-policy").

> If there
> are two tabs in gnome-terminal and the user detaches one then they cannot
> reattach it again because the tab bar is no longer visible. 

I cannot reproduce it. You can drop the tab anywhere in the window (on the other remaining tab label, or onto the actual terminal area) and it still works for me. Please be more specific (distro, Gtk and g-t version etc., perhaps a screencast as well) if you still have troubles.

> Tab bar should not be visible if the settings are set to open new window as
> a window and not a tab.

The menu entry now does either one of these two operations based on your settings, however, there's still a separate shortcut for the two. The DND behavior should be independent from the new tab policy.

Running fedora 24 here. If you detach a tab when there are two tabs the tab strip disappears. There is no way or reattaching a detached tab back onto its original parent as there are no longer any tabs to drag onto the terminal area.

Just tried opening two tabs on terminal, detaching one and then opening new tab on second window to get tab strip back so I could test attaching a tab to an existing window by dragging to the terminal area like you described and gnome-terminal crashed.

Sorry, I though you had troubles with the "drop" part of drag-n-drop. Now I understand you cannot drag it.

You can set "tab-policy" to "always" in dconf-editor, or open a new intermittent tab in order to be able to drag.

As for the crash: there's bug 763718, and there was another one filed a couple of days ago with a stack trace showing a Gtk+ bug but I just can't find that one.

It seems odd that there is a separate dconf setting for it. When the user sets the terminal to open a window in a new window they don't expect tabs or strip. When they select to open new window in tab they expect the strip so that they can combine and detach at will. Having to open a new window in order to get the tab strip to appear again to re-attach the previous window seems really strange from a ux point of view and kind of hard to describe in a bug report as well :P

This is getting heavily opinion-based. (I, for one, don't understand why the separate "New Tab" and "New Window" menu entries were merged into a single "New Terminal" with a corresponding setting.)

The use case you're describing in this bugreport requires that you use multiple windows as well as multiple tabs at the same time. You opened them by whatever means, I don't think it's relevant how you opened them, and I can't see why the "default" way of opening a new terminal should matter (since you had the use the "non-default" way too).

Yep this UI is weird, but having a tab bar with a single tab label wasting precious screen real estate is also weird. That's why you have a config option. You can't have all the benefits at the same time.

Thanks for the input. I was filling this bug on behalf of someone who is providing support on #gnome freenode channel. This seems like a common complaint there from what I could gather, its probably due to assumptions about behavior people have when dealing with tabs from their web browsers. 
I understand epiphany has the same problem. 
The solution to fix behavior would be to by default make tab strip visible at all times below window decoration when user chooses to use tabs or to integrate tab strip in csd if you want to trim down vertical screen real-estate. 
The behavior for chrome/firefox is that when the user detaches a tab they can grab the tab in new window and reattach to old window.

I'm not sure I understand what you mean about creating a window in a non default way. The way the setting is phrased is being interpreted as use tabs to manage windows or don't use tabs to manage windows. I think that's where the confusion is.

(In reply to mrmcq2u from comment #8)

> The solution to fix behavior would be to [...]

I don't see the bug. There are multiple possible UI designs, each having their advantages and disadvantages. Sure the current one has disadvantages too. You only seem to focus on your pet peeve issue, ignoring that "fixing" that would "break" something else. It's unclear to me what you're exactly recommending, as well as why you think that that'd be an overall better solution (all aspects taken into account).

Its not my "pet peeve issue", it was reported on irc by your users. I am posting a bug officially on behalf of someone who was trying to offer support for your users on unofficial gnome channel.

What do the proposed solutions break exactly?

I'm not sure why things have turned confrontational.

Spoke with developers on irc about potential solutions.
What I am recommending is that we don't break ux if a user decides they prefer working with tabs over windows. If they don't want to see a tab strip they can use windows instead of tabs, making tab strip always visible when a user chooses to open a new window using tabs seems like the best choice if you do not want to move to csd, if you do move to csd it would be possible to implement dnd to reattach a window with no tab strip visible.

If you don't want to acknowledge this as a bug that's fine. I don't really have the time to be doing this on other peoples behalf anyway. It's been filled officially, that's what counts. 

Thanks for taking the time to review this. Good night.

(In reply to mrmcq2u from comment #11)

> What do the proposed solutions break exactly?

It's unclear to me what your proposed solution is exactly. It would, however, waste precious screen real estate for no or marginal use, and I'm quite certain we would receive reports about that as well.

You're not requesting something new that doesn't exist, you're just requesting to change the default. Could you please, for the time being, direct your users to dconf-editor and ask them to change "tab-policy" to "always"? Would this fix their issues?

> What I am recommending is that we don't break ux if a user decides they
> prefer working with tabs over windows. If they don't want to see a tab strip
> they can use windows instead of tabs [...]

You keep having this separation about users who prefer windows vs. users who prefer tabs. I think this separation is wrong because:

- you can easily have windows and tabs at the same time;

- if you prefer shortcut keys over menu entries then the corresponding setting is absolutely irrelevant;

- I don't like the single "open terminal" menu entry with the corresponding "open new terminals in:" preference, I'd prefer two menu entries "open window" and "open tab" as it used to be. (I'm not the one making the final decisions in this project.) In the mean time, I really don't think the DND behavior should depend on the menu entries' design at all (and whatever you're asking for couldn't be interpreted if we had the two separate menu entries);

- in order for the current "nowhere to drag" issue to occur (and to make sense to drag), you actually do need to have multiple windows (otherwise where'd you want to drop the only tab of the source window?) as well as the intent to have multiple tabs in one of them (as the result of this DND in the destination window). So anyone facing the current issue must be a user who does actually use multiple windows as well as multiple tabs at the same time. You cannot categorize them as "window users" or "tab users".

> making tab strip always visible when a
> user chooses to open a new window using tabs seems like the best choice

This would IMO wash together two independent features which only have a slight correlation (if at all).

If we do anything at all, I'd personally be up for making a new checkbox in the prefs dialog for this currently hidden setting.

(In reply to Egmont Koblinger from comment #10)
> (In reply to mrmcq2u from comment #8)
> 
> > The solution to fix behavior would be to [...]
> 
> I don't see the bug. There are multiple possible UI designs, each having
> their advantages and disadvantages. Sure the current one has disadvantages
> too. You only seem to focus on your pet peeve issue, ignoring that "fixing"
> that would "break" something else. It's unclear to me what you're exactly
> recommending, as well as why you think that that'd be an overall better
> solution (all aspects taken into account).

I am the guy who read the gnome-terminal rages in freenode and tried to help the users there. It is hard to explain them that consistent constraints seem to be more important that consistent functionality. Can you explain me please, what would be "broken" if you add the missing undo function for undocking?

So far there was not a single word about "undo"ing something, nor about "undocking".

Now I am completely lost what you guys are having a problem with, or requesting.

The initial problem was the following:

1. You have a gnome-terminal with 2 tabs
2. You undock one tab into a window
3. How do you dock it back again (or undo it)? There is no tabbar anywhere anymore until you add new tabs to both windows, which is a weird workaround for something that should be possible somehow.

In the irc.gnome.org #gnome channel we've discussed about it and we finally came to the compromise that always showing the tab bar when the "open new terminals in new tab" option is on. The last guy from #freenode who came up with this problem suggested an option in the options to always show the tab bar. This however is not my absolute favorite solution, since undoing actions should be easily possible especially in such situations where you are able to mistakenly drag'n'drop a tab out.

(In reply to Daniel B. from comment #15)

> 3. How do you dock it back again (or undo it)?

As I've previously said, set the hidden dconf setting "tab-policy" to "always". (Use dconf-editor's "Find" functionality to locate it.)

> In the irc.gnome.org #gnome channel we've discussed about it and we finally
> came to the compromise that always showing the tab bar when the "open new
> terminals in new tab" option is on.

I still can't see any connection between these two features.

If I understand you correctly, you're arguing that if the user configures the "New Terminal" menu entry to open a new _tab_ (while standalone shortcuts Ctrl+Shift+N for new window and Ctrl+Shift+T for new tab are still available) then it's important to be able to "undock" this tab and "dock back" later; whereas if he configures "New Terminal" to open a new _window_ instead (still keeping the direct C+S+N and C+S+T shortcuts for the two actions separately) then docking-undocking is suddenly no longer a feature that you miss. This just doesn't make any sense to me.

Make up your mind whether simply DNDing or saving on screen real estate is more important for you. Set "tab-policy" accordigly and you're done. Is there anything else I'm missing?

Note #1: I'm in favor of unhiding this setting, making available on the Preferences UI.

Note #2: I'd probably be in favor of changing the default to "always". It's weird that the "new tab" button is only shown after you've once opened a new tab (by some other means) and it's also weird that the window size changes upon opening/closing a tab. I think the default should be the more novice-friendly setting and not the more expert-friendly, which is "always" in this case.

Note #3: I still don't any the point in this setting auto-following the new terminal window vs. tab preference.

(In reply to Egmont Koblinger from comment #16)
> (In reply to Daniel B. from comment #15)
> 
> > 3. How do you dock it back again (or undo it)?
> 
> As I've previously said, set the hidden dconf setting "tab-policy" to
> "always". (Use dconf-editor's "Find" functionality to locate it.)

Yes of course, but thats not a real end-user solution. I'm very thankful for this workaround till then.

> > In the irc.gnome.org #gnome channel we've discussed about it and we finally
> > came to the compromise that always showing the tab bar when the "open new
> > terminals in new tab" option is on.
> 
> I still can't see any connection between these two features.

Me neither, but that ended the discussion's back and forth. Someone told us that the users would either use tabs or windows, but never both (I use both, because too many tabs are also bad, I group terminals in windows, but use windows as a higher level grouping).

> If I understand you correctly, you're arguing that if the user configures
> the "New Terminal" menu entry to open a new _tab_ (while standalone
> shortcuts Ctrl+Shift+N for new window and Ctrl+Shift+T for new tab are still
> available) then it's important to be able to "undock" this tab and "dock
> back" later; whereas if he configures "New Terminal" to open a new _window_
> instead (still keeping the direct C+S+N and C+S+T shortcuts for the two
> actions separately) then docking-undocking is suddenly no longer a feature
> that you miss. This just doesn't make any sense to me.

The guy who thought tabs are bad wasn't convincable otherwise.

> Note #1: I'm in favor of unhiding this setting, making available on the
> Preferences UI.

Nice!

> Note #2: I'd probably be in favor of changing the default to "always". It's
> weird that the "new tab" button is only shown after you've once opened a new
> tab (by some other means) and it's also weird that the window size changes
> upon opening/closing a tab. I think the default should be the more
> novice-friendly setting and not the more expert-friendly, which is "always"
> in this case.

Even better!

> Note #3: I still don't any the point in this setting auto-following the new
> terminal window vs. tab preference.

That was just because the tabs-are-bad guy didn't want any possible changes for the non-tabs users I think.

(In reply to Daniel B. from comment #17)

> [...] users would either use tabs or windows, but never both [...]

In that case there's never a need for dragging a single tab, unless for undoing an accidental "undocking" drag. It just occurred to me that this could be the missing step: I thought you were talking about desired _intentional_ behavior. But now I believe you're worried about the case where someone wishes to use tabs only, but _accidentally_ drags out a tab to a new window, and there's no way to undo it?

@chpe What do you think about Notes #1 and #2 above?

Sorry I couldn't answer sooner.

(In reply to Egmont Koblinger from comment #18)
> (In reply to Daniel B. from comment #17)
> 
> > [...] users would either use tabs or windows, but never both [...]
> 
> In that case there's never a need for dragging a single tab, unless for
> undoing an accidental "undocking" drag. It just occurred to me that this
> could be the missing step: I thought you were talking about desired
> _intentional_ behavior. But now I believe you're worried about the case
> where someone wishes to use tabs only, but _accidentally_ drags out a tab to
> a new window, and there's no way to undo it?

I don't know how the people use it. There needs to be a user study if it is intentional or accidental. In my opinion multiple tabs and multiple windows should not exclude each other. I completely agree with your notes as solution.

Agreed on #1 and #3. Not sure on #2 though.

Just to add a use case:

I have just recently upgrade from Jessie to Stretch so I have been experiencing this change in behavior (not being able to reattach tabs) only in the last few weeks.  It has significantly reduced my productivity.

The use case: I develop web applications on a system with two monitors.  One is reserved for the browser the other has two split gnome-terminal windows.  Both windows hold ssh sessions to remote machines.  The left window is my reference window the right window is my working window.  Both windows contain multiple tabs.  On the left I could be viewing log files, checklists or man pages in different tabs.  On the right I could be editing source files, notes or administrative files [fstab/hosts what have you].

In Jessie I was free to drag checklists or administrative files from one window to the the other, depending on whether I was editing the file or using it as a reference.  That doesn't work anymore and I now I either find myself constantly juggling the windows by detaching tabs and closing them later or even reopening the same files in the other window.  Of course sometimes that just seems to silly and I simply work with the tab that's there.

But my small brain has a really hard time adapting to always reevaluating which side is the reference side and which side is the working side.  I would really appreciate it, if tabs could be moved between windows again, as this is causing a real efficiency downgrade for me.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/7678.