Public bug reported:
I was going to report this upstream, but then I remembered that type-
ahead selection of files was removed by retarted upstream Nautilus
maintainers, and it has been patched back by Ubuntu as per
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1164016
So:
Steps to reproduce:
1) Have a folder with these files:
aaa.txt
aaa.txt~ (hidden)
aab.txt~ (hidden)
aac.txt
2) Open the folder in Nautilus; make sure that the "show hidden files"
option is NOT enabled
=> so you only see aaa.txt and aac.txt
3) Type: "aa"
4) Hit the down arrow key several times.
Expected behavior:
* Since hidden files are not being shown, they should not be selectable by
type-ahead. Hence,
- after typing "aa", aaa.txt should be selected
- at the first keystroke on the down arrow, aac.txt should be selected
Observed behavior:
- After typing "aa", aaa.txt is selected, as expected
- At the first keystroke on the down arrow, no file seems to be selected.
aaa.txt is no longer highlighted but aac.txt isn't either. Under the hood, I
guess the aaa.txt~ file is "somehow selected" (but if you hit Enter nothing
happens, thank god)
- At the second keystroke, still nothing seems to change: still no file
apparently selected. But under the hood, aab.txt~ is probably "somehow selected"
- At the third keystroke, finally aac.txt is selected, proving that Nautilus is
somehow selecting files even if they are hidden.
Behaving like a file is selected (in that the previous selected one is
unselected and that you can skip to the next one) while it is not even
visible is INCONSISTENT.
The most reasonable expected behavior is to select and loop through only
visible files, so, if hidden files aren't being shown, only non-hidden
files must be considered, while if hidden files are being shown, then
they must be considered.
Another sensible behavior could be to make the hidden files that match
the typed string become visible, and highlight them when they are
selected, but that would eventually lead to counterintuitive behavior
and design issues (what do you do when the type-ahead box disappear?
turn back the hidden files to invisible?)
== ANOTHER EXAMPLE ==
Say you have, in a folder:
aaa.txt~ (hidden)
aab.txt
You type "aa"
Expected: aab.txt should be highlighted and selected
Observed: nothing is highlighted, which is exactly the same that would
happen if no file matching the typed string existed. So you may even
think the file doesn't exist (if you don't look carefully enough, which
usually you don't want to, because that is why you use type-ahead in the
first place), or you see it right in front of your eyes and you say "why
the heck isn't it found??". Only if you think about using the arrow keys
you will realize that the file you're looking for actually exists.
Which means that TYPE-AHEAD IS BASICALLY UNRELIABLE: you type something,
you see nothing selected, and that's no guarantee that no matching file
exists, until you use up/down arrow keys. (actually, you will never be
sure: what if there were hundreds of hidden files starting with the
typed string? Unlikely but possible)
The whole design of the type-ahead find thingie (which is a very useful, vital
feature) is actually shitty. It lacks at least one of two things: either
1) showing the number of matches found
or
2) changing the color of the typed text or its background when no match is found
ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: nautilus 1:3.10.1-0ubuntu9.7
ProcVersionSignature: Ubuntu 3.13.0-55.94-generic 3.13.11-ckt20
Uname: Linux 3.13.0-55-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.11
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Jul 22 23:29:18 2015
GsettingsChanges:
b'org.gnome.nautilus.list-view' b'use-tree-view' b'true'
b'org.gnome.nautilus.list-view' b'default-column-order' b"['name', 'size',
'type', 'date_modified', 'date_accessed', 'owner', 'group', 'permissions',
'mime_type', 'where']"
InstallationDate: Installed on 2013-10-11 (649 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
SourcePackage: nautilus
UpgradeStatus: Upgraded to trusty on 2014-05-24 (424 days ago)
** Affects: nautilus (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug trusty
** Description changed:
I was going to report this upstream, but then I remembered that type-
ahead selection of files was removed by retarted upstream Nautilus
maintainers, and it has been patched back by Ubuntu as per
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1164016
So:
Steps to reproduce:
1) Have a folder with these files:
- aaa.txt
- aaa.txt~ (hidden)
- aab.txt~ (hidden)
- aac.txt
+ aaa.txt
+ aaa.txt~ (hidden)
+ aab.txt~ (hidden)
+ aac.txt
2) Open the folder in Nautilus; make sure that the "show hidden files"
option is NOT enabled
- => so you only see aaa.txt and aac.txt
+ => so you only see aaa.txt and aac.txt
3) Type: "aa"
4) Hit the down arrow key several times.
Expected behavior:
- * Since hidden files are not being shown, they should not be selectable by
type-ahead. Hence,
+ * Since hidden files are not being shown, they should not be selectable by
type-ahead. Hence,
- after typing "aa", aaa.txt should be selected
- at the first keystroke on the down arrow, aac.txt should be selected
-
Observed behavior:
- After typing "aa", aaa.txt is selected, as expected
- At the first keystroke on the down arrow, no file seems to be selected.
aaa.txt is no longer highlighted but aac.txt isn't either. Under the hood, I
guess the aaa.txt~ file is "somehow selected" (but if you hit Enter nothing
happens, thank god)
- At the second keystroke, still nothing seems to change: still no file
apparently selected. But under the hood, aab.txt~ is probably "somehow selected"
- At the third keystroke, finally aac.txt is selected, proving that Nautilus
is somehow selecting files even if they are hidden.
-
- Behaving like a file is selected (in that the previous selected one is
unselected and that you can skip to the next one) while it is not even visible
is INCONSISTENT.
+ Behaving like a file is selected (in that the previous selected one is
+ unselected and that you can skip to the next one) while it is not even
+ visible is INCONSISTENT.
The most reasonable expected behavior is to select and loop through only
visible files, so, if hidden files aren't being shown, only non-hidden
files must be considered, while if hidden files are being shown, then
they must be considered.
Another sensible behavior could be to make the hidden files that match
the typed string become visible, and highlight them when they are
selected, but that would eventually lead to counterintuitive behavior
and design issues (what do you do when the type-ahead box disappear?
turn back the hidden files to invisible?)
-
== ANOTHER EXAMPLE ==
Say you have, in a folder:
- aaa.txt~ (hidden)
- aab.txt
+ aaa.txt~ (hidden)
+ aab.txt
You type "aa"
Expected: aab.txt should be highlighted and selected
Observed: nothing is highlighted, which is exactly the same that would
happen if no file matching the typed string existed. So you may even
think the file doesn't exist (if you don't look carefully enough, which
usually you don't want to, because that is why you use type-ahead in the
first place), or you see it right in front of your eyes and you say "why
the heck isn't it found??". Only if you think about using the arrow keys
you will realize that the file you're looking for actually exists.
-
- Which means that TYPE-AHEAD IS BASICALLY UNRELIABLE: you type something, you
see nothing selected, and that's no guarantee that no matching file exists,
until you use up/down arrow keys.
-
+ Which means that TYPE-AHEAD IS BASICALLY UNRELIABLE: you type something,
+ you see nothing selected, and that's no guarantee that no matching file
+ exists, until you use up/down arrow keys. (actually, you will never be
+ sure: what if there were hundreds of hidden files starting with the
+ typed string? Unlikely but possible)
The whole design of the type-ahead find thingie (which is a very useful,
vital feature) is actually shitty. It lacks at least one of two things: either
1) showing the number of matches found
or
2) changing the color of the typed text or its background when no match is
found
ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: nautilus 1:3.10.1-0ubuntu9.7
ProcVersionSignature: Ubuntu 3.13.0-55.94-generic 3.13.11-ckt20
Uname: Linux 3.13.0-55-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.11
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Jul 22 23:29:18 2015
GsettingsChanges:
- b'org.gnome.nautilus.list-view' b'use-tree-view' b'true'
- b'org.gnome.nautilus.list-view' b'default-column-order' b"['name', 'size',
'type', 'date_modified', 'date_accessed', 'owner', 'group', 'permissions',
'mime_type', 'where']"
+ b'org.gnome.nautilus.list-view' b'use-tree-view' b'true'
+ b'org.gnome.nautilus.list-view' b'default-column-order' b"['name', 'size',
'type', 'date_modified', 'date_accessed', 'owner', 'group', 'permissions',
'mime_type', 'where']"
InstallationDate: Installed on 2013-10-11 (649 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
SourcePackage: nautilus
UpgradeStatus: Upgraded to trusty on 2014-05-24 (424 days ago)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1477322
Title:
Select-by-typing select hidden files even if they are not shown
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1477322/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
