GNOME Bugzilla – Bug 709109
Tab opening/closing enhancement
Last modified: 2019-11-20 22:13:45 UTC
I'd like to requet two convenience features (with respective config options): When opening a new tab, it opens next to the current one. When closing a tab, the most recently used becomes active.
Created attachment 257063 [details] [review] New tab opens adjacent to the current This implements one of the two proposed features.
Hmm. I remember we've been back and forth on this a few times in epiphany; what does it currently do, same as requested here?
epiphany-3.6.1 (shipped by ubuntu 13.10) opens new tabs on the right (like g-t), focuses the most recently used when closing one (unlike g-t), and I can't find a config option to change it.
Comment on attachment 257063 [details] [review] New tab opens adjacent to the current Can you remove the parts adding the setting to the prefs UI ? I'd like to keep this dconf only (for now at least). +#define TERMINAL_SETTING_TAB_OPENS_ADJACENT "tab-opens-adjacent" Naming nit: ..._KEY. Maybe rename the pref, "new-tab-position" with enum values "right" and "end" ?
(In reply to Christian Persch from comment #4) > I'd like to keep this dconf only (for now at least). In that case probably I'd be the only user of this feature - then it's just not worth the trouble :) IMO let's either make it a discoverable feature, or just drop the idea.
Not having 'open tab next to current' is driving me pretty nutty after getting used to SecureCRT's tab-opening behavior. I'll probably recompile gnome-terminal just for this little feature. Hope this makes it in, discoverable or not.
(In reply to Egmont Koblinger from comment #5) > (In reply to Christian Persch from comment #4) > > > I'd like to keep this dconf only (for now at least). > > In that case probably I'd be the only user of this feature - then it's just > not worth the trouble :) IMO let's either make it a discoverable feature, > or just drop the idea. Alright, ok to add UI too :-)
(In reply to Egmont Koblinger from comment #5) > In that case probably I'd be the only user of this feature - then it's just > not worth the trouble :) IMO let's either make it a discoverable feature, > or just drop the idea. Egmont, you're definitively not alone with such actually conventional feature! Thanks for the patch. I wonder whether it would be easy to backport it to mate-terminal.
Ping. Is there anything left to do apart from those mentioned in comment 4?
Since I'm ok with adding the UI, it only needs to be updated to master, and the nits from comment 4 fixed.
Created attachment 374244 [details] [review] New tab position Updated version. Switched from boolean/checkbox to enum/combobox, for future compatibility with other crazy values, as well as a more consistent look of the General prefs panel. The name and UI labels are not necessarily final. In particular, I'm thinking of changing from "new_tab_position" to "new_tab_placement", especially that we have a "tab_position" (for the entire tab bar). "Position" perhaps suggests that it's always there, whereas "placement" is a one-time action, does this make sense?
The patch looks fine, except perhaps for the terminology used. "Last" could be misunderstood to mean the position the most-recently opened tab was inserted in, and 'next' without a reference to 'next to this one' isn't too clear either. Maybe calling these 'end' for 'at the end', and 'right' (or 'after') for 'to the right of/after the current tab' would be clearer?
That concerns just the presentation in the UI; the pref values are ok. Although I guess if we change the names in the UI before this is committed, we can just change the pref values too. Or commit as-is and if it turns out to be confusing, just change the UI names.
Yup I agree that the wording is quite bad, and I haven't even though of: > "Last" could be misunderstood to [...] the most-recently opened which is indeed also true. We should come up with something better. Or look around in existing software (e.g. firefox's tab mix plus). > we can just change the pref values too I'm on this side: prefer to have the same internal terminology (even if they might diverge later). I'm not in constructive mood right now to propose anything better :)
Ok, let's go with the patch as-is and amend later as needed.
Pushed to master. Thanks!