Bug#728681: nautilus: keyboard browsing no longer available
James McCaw
james.mccaw at gmail.com
Mon Nov 4 04:08:59 UTC 2013
Package: nautilus
Version: 3.8.2-2
Severity: normal
Tags: upstream
Dear Maintainer,
As heavily discussed upstream [0][1] but not yet reported as a bug in debian
(this report changes that), changes introduced in version 3.6 of nautilus
lead
to a serious UI regression for the default file *manager* on the debian
desktop.
The removal of type-ahead browsing has fundamentally changed the behaviour
of
the file browser, and it is now impossible to *browse* the filesystem
without
the use of a mouse. The improved *search* functionality is fantastic, but is
fundametnally a different activity to browsing.
The at times unpleasant and strained conversations in other bugs reports
need
not be repeated here, but from my careful reading stem from some individuals
having a lack of distinction between the two logically different operations
of
searching and browsing.
Upstream, as is their right, have chosen to attempt to design a UI that
pulls
the concept of browsing into the domain of a search, but I would argue that
even if (infinitely) fast and very smart, search cannot logically be a
replacement for browsing.
The fundamental distinction that separates browsing and search (no matter
how
fast and smart that search becomes) is very simple:
search is a filter, presenting results from some specified condition.
type-ahead (browsing) is not filter, but a way to move the "cursor" to the
desired location within the existing (and critically unfiltered/unchanged)
context.
To my mind, anything and everything else discussed around this [0][1] (e.g.
speed, relevance of search-returns) etc is actually of (a distant) secondary
importance.
And so to the essence of this bug:
REGRESSION: The nautilus file browser no longer has a keyboard operated
browsing mechanism*
*To be 100% clear, it does now have a very fast and impressively smart
keyboard
operated searching mechanism that prioritizes results from the current
directory, but as per my argument, this is completely irrelevant for the use
case of browsing.
With that summary, and my (perhaps flawed) attempt to describe the *logical*
(and certainly not *UI design choice*) issue here, comes the difficult bit:
How can debian resolve this bug? Users of sid (right now) and testing (soon)
are about to be bitten. Options include:
1. Restoring the lost browsing functionality (type-ahead find) through a
patch
to nautilus 3.8(sid/testing) or 3.10(experimental) - very difficult
presumably
without support of upstream (who are very clear on not re-implementing this
browsing feature, as they firmly believe that the two concepts of search and
browse can be merged) but in the end the only viable solution (short of
convincing upstream to change policy).
2. Pulling nautilus 3.4 into gnome 3.8/3.10 - presumably completely
impractical
and with escalating difficulty as time goes on.
3. Replacing the default file-manager in debian's gnome with nemo - this
could
be achieved fairly simply (I've done so on my system) but would be rather
odd
from a whole of desktop distribution point of view to have one non-gnome
piece
of software replacing one of the core upstream elements of gnome.
My intention here is not to start the same sequence of arguments in debian
as
have occurred upstream (they can be read in detail at your leisure [0][1]),
but
to ensure that debian has an explicitly acknowledged representation to (and
from) its community that this issue is here.
I personally think this is worthy of status SEVERE or even GRAVE if one can
extend those categories beyond technical elements of software and into the
realm of the human interaction with (and reaction to) it. It is one of the
most
intrusive and difficult to deal with changes in UI that I have experienced
in
over 20 years of linux use. gnome3 (which I love) is a UI design choice -
intrusive but a UI *choice*. This bug is a fundamental muddling up of
different
*logical* operations that one may want to perform (which I think explains a
lot
of the animosity between those people who see the logical issue here and
those
who argue that a clever search UI can provide the functionality).
[0] https://bugzilla.gnome.org/show_bug.cgi?id=680849
[1] https://bugzilla.gnome.org/show_bug.cgi?id=680118
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (800, 'testing'), (700, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.10-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages nautilus depends on:
ii desktop-file-utils 0.22-1
ii gsettings-desktop-schemas 3.8.2-2
ii gvfs 1.16.3-1+b1
ii libatk1.0-0 2.10.0-2
ii libc6 2.17-93
ii libcairo-gobject2 1.12.16-2
ii libcairo2 1.12.16-2
ii libexempi3 2.2.1-1
ii libexif12 0.6.21-1
ii libgail-3-0 3.8.6-1
ii libgdk-pixbuf2.0-0 2.28.2-1
ii libglib2.0-0 2.36.4-1
ii libglib2.0-data 2.36.4-1
ii libgnome-desktop-3-7 3.8.4-2
ii libgtk-3-0 3.8.6-1
ii libnautilus-extension1a 3.4.2-2
ii libnotify4 0.7.6-1
ii libpango-1.0-0 1.36.0-1
ii libpangocairo-1.0-0 1.36.0-1
ii libselinux1 2.2-2
ii libtracker-sparql-0.16-0 0.16.2-1
ii libx11-6 2:1.6.2-1
ii libxml2 2.9.1+dfsg1-3
ii nautilus-data 3.8.2-2
ii shared-mime-info 1.0-1+b1
Versions of packages nautilus recommends:
ii eject 2.1.5+deb1+cvs20081104-13
ii gnome-icon-theme-symbolic 3.10.1-1
ii gnome-sushi 3.8.1-1
ii gvfs-backends 1.16.3-1+b1
ii librsvg2-common 2.36.4-2
Versions of packages nautilus suggests:
ii brasero 3.8.0-2
ii eog 3.8.2-1
ii evince [pdf-viewer] 3.8.3-2
ii totem 3.8.2-3
ii tracker 0.16.2-1
ii xdg-user-dirs 0.15-1
-- no debconf information
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20131104/3ca9d4e6/attachment-0003.html>
More information about the pkg-gnome-maintainers
mailing list