GNOME Bugzilla – Bug 730850
Dropping a 2nd tab into a window makes it shrink
Last modified: 2014-05-29 12:08:08 UTC
Have multiple gnome-terminal windows, one with a single tab (no tab bar present), one with more tabs. Drag and drop one of the tabs into the window that has only one tab. Notice that the window shrinks. Expected: the terminal window should stay at the same grid size (i.e. enlarge its size in pixels to accomodate the new tab), exactly as when a new tab is opened with Ctrl+Shift+T. Reproducible in gnome-shell and compiz/unity.
I guess the reverse is also true, if you drag off one tab from a window with exactly two, the window doesn't shrink? Looks like missing terminal_window_update_size calls in the notebook's page added/removed handlers...
> I guess the reverse is also true, if you drag off one tab from a window with > exactly two, the window doesn't shrink? Interestingly, not :) > Looks like missing terminal_window_update_size calls in the notebook's page > added/removed handlers... Yup my guess is the same, we need to find some code that's already there when a tab is opened/closed, and copy it to when it's dragged.
Created attachment 277388 [details] [review] fix There were at least two places where the window size was correctly set: - when a tab was closed and only 1 remained - when a tab was made active (this is necessary e.g. when font sizes differ) but it was not done when a 2nd tab was added. It means that dragging away a tab actually set the correct size twice (once because another tab had to be made active, and once because there was only 1 tab remaining). Opening another tab with Ctrl+Shift+T "accidentally" set the size because this new tab was made active. On a slightly related note, I think it would better if a drag-n-dropped tab would become active in its new window – any opinions here?
Comment on attachment 277388 [details] [review] fix d3e593e
Sorry, but I don't like this patch. It's totally unobvious why this fixes the problem, and why this is necessary only here for tab-added not for tab-removed. Adding the tab to the window will make it the current tab, and the the handler for that updates the size already. So why is this not enough?
(In reply to comment #3) > On a slightly related note, I think it would better if a drag-n-dropped tab > would become active in its new window – any opinions here? Hmm it does become active here...
(In reply to comment #5) > Sorry, but I don't like this patch. It's totally unobvious why this fixes the > problem, and why this is necessary only here for tab-added not for tab-removed. For tab-removed (mdi_screen_removed_cb()) this code is already there. > Adding the tab to the window will make it the current tab, and the the handler > for that updates the size already. So why is this not enough? It's not made the current when you drop it in the terminal area (rather than on the tab bar). I'd vote for changing this behavior, but even then I think it's good to have the current patch.
(In reply to comment #7) > (In reply to comment #5) > > Sorry, but I don't like this patch. It's totally unobvious why this fixes the > > problem, and why this is necessary only here for tab-added not for tab-removed. > > For tab-removed (mdi_screen_removed_cb()) this code is already there. I missed this. Ok then, I guess this is good enough. Re-committed. > > Adding the tab to the window will make it the current tab, and the the handler > > for that updates the size already. So why is this not enough? > > It's not made the current when you drop it in the terminal area (rather than on > the tab bar). > > I'd vote for changing this behavior, but even then I think it's good to have > the current patch. Ah, right, I tested by dropping on the tab bar. Yes, let's make this consistent.