Bug #17186

"Open in terminal" has disappeared from the file explorer

Added by tobtoht 2019-10-24 13:32:08 . Updated 2019-11-14 17:38:30 .

Status:
Resolved
Priority:
Elevated
Assignee:
segfault
Category:
Target version:
Start date:
Due date:
% Done:

100%

Feature Branch:
bugfix/17186-open-in-terminal
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

In Tails 4.0 the menu option to open the terminal in the current directory by right clicking on empty space within the file explorer has disappeared.

This significantly hinders those that want to run scripts or develop on Tails.


Files

script.png (58075 B) sajolida, 2019-10-29 22:36:38

Subtasks


Related issues

Related to Tails - Bug #17195: 'Allow launching' setting is not saved New
Related to Tails - Bug #17193: Can't run .desktop files from the desktop anymore Resolved
Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed

History

#1 Updated by sajolida 2019-10-29 22:36:42

To execute a script you can drag and drop it from the Files browser into Terminal. See screenshot in attachment.

@tobtoht: Does this solve your concern?

#2 Updated by sajolida 2019-10-30 12:24:03

  • related to Bug #17195: 'Allow launching' setting is not saved added

#3 Updated by sajolida 2019-10-30 12:26:03

  • related to Bug #17193: Can't run .desktop files from the desktop anymore added

#4 Updated by emmapeel 2019-10-31 08:59:55

Another user mailed tails-bugs commenting the absence of this menu option as well.

I used it a lot myself…

#5 Updated by tobtoht 2019-10-31 09:59:56

sajolida wrote:
> To execute a script you can drag and drop it from the Files browser into Terminal. See screenshot in attachment.

No, this way dependencies that reside in the same directory as the script will not be found.

Previously there was a consistent way to instruct users on how to start a script regardless of where they chose to save it: “Move to the directory that contains the script in the file explorer, open in terminal then run this command.”

Now I need to explain what cd is and how to use it to navigate around the terminal to get to the directory where they saved the script.

#6 Updated by intrigeri 2019-10-31 10:43:20

> Now I need to explain what cd is and how to use it to navigate around the terminal to get to the directory where they saved the script.

What about this: cd + “drag’n’drop the folder into the Terminal”?

#7 Updated by intrigeri 2019-10-31 10:53:20

One can get this functionality back by adding nautilus-extension-gnome-terminal to their Additional Software.
Is this good enough? Or are there important use cases that require this feature before persistence is set up?

#8 Updated by tobtoht 2019-10-31 19:50:21

Thanks for taking the time to come up with some alternatives.

>What about this: cd + “drag’n’drop the folder into the Terminal”?

It’s still another step that I’d rather avoid having to explain.
Dragging a bookmark (e.g. Persistent) into the terminal doesn’t work. I can see users getting confused by this.

>Or are there important use cases that require this feature before persistence is set up?

Some users download the scripts when needed and use them without persistence.

>One can get this functionality back by adding nautilus-extension-gnome-terminal to their Additional Software.
>Is this good enough?

I’d also rather not have to explain how to enable additional software persistence, run two commands to install nautilus-extension-gnome-terminal, just to enable a basic feature.

Consistency is key when it comes to support. When a typical support query looks like: “help can’t open script”, having to ask whether or not a user has enabled persistence, has installed the nautilus extension, knows how to change directories with the terminal, is sure they are in the right directory, etc is a cumbersome process.

Was there any specific reasoning for the removal of this feature or is this a change from upstream?

#9 Updated by intrigeri 2019-11-01 07:00:27

> Was there any specific reasoning for the removal of this feature or is this a change from upstream?

This functionality was previously forcibly installed; then it was moved to a new, separate package (nautilus-extension-gnome-terminal), which we did not automatically get since we don’t install Recommends by default (and the only reason why this would get installed is that gnome-terminal has Recommends: nautilus-extension-gnome-terminal).

From an engineering perspective, I see no particular problem with installing nautilus-extension-gnome-terminal by default.
Given we don’t ship changelog.gz and changelog.Debian.gz in our images, it’s a matter of a few dozens KiB, maximum.
sajolida, should we “just” go ahead and add this package?

#10 Updated by emmapeel 2019-11-01 09:09:56

I would like to have it back as well (speaking as a user).

#11 Updated by numbat 2019-11-05 10:09:06

Same here. This is so useful when trying to help less-technical users.

#12 Updated by sajolida 2019-11-06 14:59:59

  • Status changed from New to Confirmed

> sajolida, should we “just” go ahead and add this package?

Yep

#13 Updated by sajolida 2019-11-06 15:07:32

I tried adding nautilus-extension-gnome-terminal to my Tails and I still can’t see the “Open in Terminal” entry when doing right-click on a script in the Files browser.

I also took care of killing any nautilus process around and restarted GNOME Shell (Alt+F2, “R”).

#14 Updated by sajolida 2019-11-06 15:08:41

  • Priority changed from Normal to Elevated

Seeing how loud this issue (and related ones) are in 4.0 and that it’s a regression, I think that it deserves “Elevated”.

#15 Updated by intrigeri 2019-11-09 09:43:06

> I tried adding nautilus-extension-gnome-terminal to my Tails and I still can’t see the “Open in Terminal” entry when doing right-click on a script in the Files browser.

Indeed, even with nautilus-extension-gnome-terminal installed, just like in Tails 3.16, this entry is only present in the menu when right-clicking in an empty space in Nautilus (which is the lost functionality this ticket initially complained about) or on a folder.

May we scope this ticket to fixing the regression only? Or do you want to extend its scope to “Open in Terminal is not proposed when right-clicking on a script”?

#16 Updated by intrigeri 2019-11-09 09:43:07

#17 Updated by intrigeri 2019-11-09 09:45:20

  • Target version set to Tails_4.1

> Seeing how loud this issue (and related ones) are in 4.0 and that it’s a regression, I think that it deserves “Elevated”.

I’ve put it on the FT’s plate (otherwise, having higher than normal priority won’t yield the effect you’re hoping for) and set its target version to 4.1.

#18 Updated by intrigeri 2019-11-10 09:22:29

  • Status changed from Confirmed to In Progress
  • Assignee set to intrigeri
  • Feature Branch set to bugfix/17186-open-in-terminal

#19 Updated by intrigeri 2019-11-10 10:00:16

  • Status changed from In Progress to Needs Validation
  • Assignee deleted (intrigeri)

intrigeri wrote:
> May we scope this ticket to fixing the regression only?

I’m optimistically assuming the answer will be yes. Built from the branch, tested manually, works as expected. I did not wait for Jenkins to run the test suite yet as I’m confident this can’t possibly break anything, and if it does, that’s trivial to revert.

#20 Updated by tobtoht 2019-11-10 11:46:50

intrigeri wrote:
> May we scope this ticket to fixing the regression only?

Yes, this is fine.

#21 Updated by segfault 2019-11-10 15:43:39

  • Assignee set to segfault

#22 Updated by segfault 2019-11-10 15:47:58

  • Status changed from Needs Validation to Resolved
  • % Done changed from 0 to 100

Applied in changeset commit:tails|63638b97d9af8a39436e690a434b0e566d03f473.

#23 Updated by sajolida 2019-11-14 17:38:30

Yes! (only understanding now what the ticket was originally about :D)