GNOME Bugzilla – Bug 744161
Can't use the gnome-terminal nautilus extension from list view
Last modified: 2016-11-05 18:19:12 UTC
The gnome-terminal nautilus extension adds a context menu item to the current directory to open a terminal there. When browsing a directory with enough files to have scrollbars however, there is no empty space to rightclick on to get to the context menu for the current directory. Previously the context menu items could also be accessed via the gear menu which helped with such situations, but this doesn't work anymore since the GAction port. The same issue also affects the menu to create new files in the current directory.
(In reply to Sebastian Keller from comment #0) > Previously the context menu items could also be accessed via the gear menu > which helped with such situations, but this doesn't work anymore since the > GAction port. Is that a problem in nautilus itself, or does the nautilus extension (which is provided by gnome-terminal) need to be adapted to GAction ?
We don't show extensions items in the toolbar anymore, so we will need a solution for list view
The solution is pretty straightforward, just have it present as a menu item in the hamburger menu in the headerbar.
*** Bug 759056 has been marked as a duplicate of this bug. ***
(In reply to Jean-François Fortin Tam from comment #3) > The solution is pretty straightforward, just have it present as a menu item > in the hamburger menu in the headerbar. Not really, we would need to do that for every item in the menu, which it's not suitable.
> we would need to do that for every item in the menu Which is almost already the case. The only missing items are: - Paste (bug #751025) - New document (bug #748057) - Properties (don't care about that one, esp. since you can do that by rightclicking the last breadcrumb) > which it's not suitable. Aesthetic length of a menu does not have priority over actually being able to access a feature, in my humble opinion...
Hi. In my humble opinion too, the features are developed for work, not to "seem work". If one feature have "inconvenients", better work to resolve the question. It is so difficult add a button for the feature, like Nemo, i. e., does? Best regards. Will
(In reply to Jean-François Fortin Tam from comment #6) > > we would need to do that for every item in the menu > > Which is almost already the case. The only missing items are: > - Paste (bug #751025) > - New document (bug #748057) > - Properties (don't care about that one, esp. since you can do that by > rightclicking the last breadcrumb) > > > which it's not suitable. > > Aesthetic length of a menu does not have priority over actually being able > to access a feature, in my humble opinion... I lend to agree with you, however that menu it's not contextual at all (except some items like undo and redo getting enable and disabled), that menu is static. Adding items depending on the location and extensions will break this, and I'm not sure the hamburger menu is the one to be changing. Also this needs more though as it class with other menu experiments designers are thinking about.
(In reply to wil111ber-cont from comment #7) > Hi. > In my humble opinion too, the features are developed for work, not to "seem > work". If one feature have "inconvenients", better work to resolve the > question. It is so difficult add a button for the feature, like Nemo, i. e., > does? > Best regards. > Will Yep, however imho that's not the best solution one can think. That's what needs work. Adding a random button is certainly easy. Doing a good solution is not.
Hi, Carlos. I don't understand "random button" in this context. The button is, obviously, for the feature "Open (the actual folder) in terminal" only. Until we have "the best solution", why don't have a simple and useful button? Will
(In reply to wil111ber-cont from comment #10) > Hi, Carlos. > I don't understand "random button" in this context. The button is, > obviously, for the feature "Open (the actual folder) in terminal" only. > Until we have "the best solution", why don't have a simple and useful button? > > Will Let me explain then: the open terminal option is actually not in nautilus, you installed a nautilus extension which adds that item, we cannot control that. That "simple button" is actually a programatically added button by the extension you installed, therefore, you can guess, any extension can add any number of items, and we cannot control them. To add on it, even you could think this "open in terminal" item would be the most important one, but reality is that other people they have their own "important ones", and to fulfill all of those needs we cannot add 100 options to handle them. That's when design and overflow handling enters the game, and we need a good solution for that. However, it's true "open in terminal" is one of the most desired items, but that's not an excuse to make the other extensions less convenient. Could be something to think if we want that inside Nautilus itself, but the answer is we don't for now.
Well, end of history. I renounce and will use Nemo for this purpose. Thanks in any case. Will
It may be heretic, but one option would be to turn "Launch gnome-terminal" from a random extension into core functionality. If you do so, be ready for the onslaught of the "my favorite terminal" crowd.
(In reply to Matthias Clasen from comment #13) > It may be heretic, but one option would be to turn "Launch gnome-terminal" > from a random extension into core functionality. If you do so, be ready for > the onslaught of the "my favorite terminal" crowd. Actually, we don't need to specify the terminal, the user could still have a preferred one. This is how it launch a terminal the (legacy now) separated nautilus open terminal plugin: https://git.gnome.org/browse/nautilus-open-terminal/tree/src/nautilus-open-terminal.c#n326 To be honest, I'm not aware of the history of the "Open in terminal" thing, and why was removed. I can guess it's because looks like a perfect fit for an extension, rather than something the file manager should do.
(In reply to Carlos Soriano from comment #14) > (In reply to Matthias Clasen from comment #13) > > It may be heretic, but one option would be to turn "Launch gnome-terminal" > > from a random extension into core functionality. If you do so, be ready for > > the onslaught of the "my favorite terminal" crowd. > > Actually, we don't need to specify the terminal, the user could still have a > preferred one. Matthias might be hinting at bug 627943
> > Matthias might be hinting at bug 627943 Aha, I didn't know that. Thanks Rishi.
Discussions about behaviour of the extension set aside (which is not what the original report is about anyway), this is a duplicate of bug 689768. *** This bug has been marked as a duplicate of bug 689768 ***