Avainsanana Nautilus

Position of left-tiled windows not restored correctly when another left-tiled window present

18. toukokuuta 2018 klo 15.38
Sijainti: Vianhallintajärjestelmät: Gnome GitLab
Avainsanat: Firefox, Gnome, Launchpad, Nautilus

Background

I’m using Ubuntu 18.04 with Gnome Shell 3.28.1, and was forwarded here from Launchpad, see bug #1767806 there.

The issue

When another window is maximized or tiled to the left side of the screen, re-opening an application whose window was previously tiled to the left side does not restore that windows’ previous position. Instead such windows open at varying distances from the dock, untiled.

Expected behavior

Steps to reproduce (with a newly created user)

  1. open Firefox, drag the window to the left edge of the screen to tile it there (filling up the left half of horizontal screen space)
  2. close Firefox
  3. open Nautilus, make sure that the window floats (i.e. is unmaximized and not tiled to either side of screen)
  4. open Firefox

What happens

As expected, Firefox’s window is tiled to the left edge of screen, immediately to the right side of the dock: screenshot.

Unexpected behavior

Steps to reproduce (with a newly created user)

  1. open Firefox, drag the window to the left edge of the screen to tile it there (filling up the left half of horizontal screen space)
  2. close Firefox
  3. open Nautilus, maximize its window
  4. open Firefox

What happens

Firefox’s window opens slightly to the right off the right edge of the dock (with a gap between the dock and the window): screenshot.

What I expect to happen

I expect Firefox’s window to be tiled to the left edge of screen, immediately to the right side of the dock, just as it did following the first recipe above.

Further information

  • Either maximizing or tiling Nautilus’ window to the left edge of the screen (at step 3) triggers the issue. Tiling it to the right edge of the screen does not.
  • Using Gnome Terminal instead of Nautilus triggers the issue just as well and I suspect any other application will, though I’ve only systematically tested these two so far.
  • From battling with this in my daily use I also know that the distance of incorrectly restored windows from the dock varies: different applications open at different distances. The precise mechanics of this still elude me, though the distances do appear to be multiples of 25 pixels.

Vastaa viestiin sen kontekstissa (Gnome GitLab)

Possible duplicates with bug #1607919

9. huhtikuuta 2018 klo 15.26
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: Gnome, Nautilus

Possible duplicates with bug #1607919

Vastaa viestiin sen kontekstissa (Launchpad)

nautilus crashed with SIGSEGV in nautilus_list_model_get_all_iters_for_file() when trying to open a password-protected 7z archive

9. huhtikuuta 2018 klo 15.10
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: Gnome, Nautilus

== Steps to reproduce ==
1. Create a password protected 7z archive: `echo hello >hello.txt; 7z a hello.7z hello.txt -ppassword`
2. Left-click the archive in Nautilus

== What happens ==
Nautilus shows an empty window, and together with gnome-shell they eat up the CPU until you close the Nautilus window. Alternatively, a crash report prompt appears.

== What I expect to happen ==
Preferably to prompt for a password and then open the archive contents. At the very least to not eat all the CPU, and inform the user that Nautilus is incapable of handling this file format.

== Other info ==
I don’t have Dropbox installed unlike in bug #1734891.

Upstream issue: https://gitlab.gnome.org/GNOME/nautilus/issues/51

Red Hat issue: https://bugzilla.redhat.com/show_bug.cgi?id=1499401

Vastaa viestiin sen kontekstissa (Launchpad)

This does indeed seem to be fixed Vivid

4. helmikuuta 2015 klo 18.28
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: Nautilus

This does indeed seem to be fixed Vivid. Nautilus now has two options to remember the credentials (till logout or forever), and both seem to do what it says on the tin.

Vastaa viestiin sen kontekstissa (Launchpad)

Also affects 12.04 (with gedit 3.4.1-0ubuntu1).

14. huhtikuuta 2014 klo 18.46
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: gedit, Gnome, Nautilus

Also affects 12.04 (with gedit 3.4.1-0ubuntu1).

Vastaa viestiin sen kontekstissa (Launchpad)

When the selected/renamed file is a directory: see Bug #1105232.

14. huhtikuuta 2014 klo 18.42
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: gedit, Gnome, Nautilus

When the selected/renamed file is a directory: see Bug #1105232.

Vastaa viestiin sen kontekstissa (Launchpad)

Nautilus copy from commandline

30. kesäkuuta 2012 klo 22.22
Sijainti: Muut: Launchpad
Avainsanat: Gnome, Nautilus

Apparently this is now supported; at least the following seems to work under 12.04:

$ qdbus org.gnome.Nautilus /org/gnome/Nautilus org.gnome.Nautilus.FileOperations.CopyFile "file:///source/directory" "*" "file:///destination/directory" "" 

where /source/directory is the absolute path to your source directory, * is the glob for file[s] to copy,/destination/directory is your destination directory and the last ”” is for destination file name. Note that you need to have the last one there even if it’s empty as in here, to fulfill the method signature. Also, if you specify a target name and have multiple source files, they’ll all get copied to that one destination file, giving an overwrite prompt for each file after the first one (which may or may not be what you want).

Vastaa viestiin sen kontekstissa (Launchpad)

Move to trash undoing fails when path contains Scandinavian letters

9. huhtikuuta 2012 klo 16.43
Sijainti: Vianhallintajärjestelmät: GNOME Bugzilla
Avainsanat: Gnome, Nautilus

I reported this on Launchpad [1] and was forwarded upstream.

Steps to reproduce:
1. touch ~/foo_åäö
2. In Nautilus, point at the file created in step 1
3. Right-click for context menu
4. Select Move to Trash
5. Press Ctrl-Z/Select Undo from the Edit menu

What happens:
Nothing

What I expect to happen:
For the file to recover from trash to ~.

What works:
* Undoing Move to Trash with files with no scandinavian letters in their path/filename.
* Recovering foo_åäö by opening Trash and selecting Recover from context menu.

More info:
* Could be that more characters, perhaps all non-ASCII characters render Nautilus’ Undo impotent — I’ve only tested å, ä and ö.
* The Finnish translation for Desktop (~/Desktop) is Työpöytä, which means files moved to trash from Desktop can’t be recovered. Nasty.

*[1] https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/973620

Vastaa viestiin sen kontekstissa (GNOME Bugzilla)

Move to trash undoing fails when path contains Scandinavian letters

4. huhtikuuta 2012 klo 21.05
Sijainti: Vianhallintajärjestelmät: Launchpad
Avainsanat: Nautilus, saavutettavuus

Steps to reproduce:
1. touch ~/foo_åäö
2. In Nautilus, point at the file created in step 1
3. Right-click for context menu
4. Select Move to Trash
5. Press Ctrl-Z/Select Undo from the Edit menu

What happens:
Nothing

What I expect to happen:
For the file to recover from trash to ~.

What works:
* Undoing Move to Trash with files with no scandinavian letters in their path/filename.
* Recovering foo_åäö by opening Trash and selecting Recover from context menu.

More info:
* Could be that more characters, perhaps all non-ASCII characters render Nautilus’ Undo impotent — I’ve only tested å, ä and ö.
* The Finnish translation for Desktop (~/Desktop) is Työpöytä, which means files moved to trash from Desktop can’t be recovered. Nasty.

Vastaa viestiin sen kontekstissa (Launchpad)

GNOME nautilus 3.4.0

28. maaliskuuta 2012 klo 19.42
Sijainti: Vianhallintajärjestelmät: GNOME Bugzilla
Avainsanat: Nautilus

jani@saegusa:~$ nautilus –version
GNOME nautilus 3.4.0

Vastaa viestiin sen kontekstissa (GNOME Bugzilla)

Vanhempia »