Re: RFC: On-line Content Filtering of directories

[Ryan McDougall <NQG24419 nifty com>]

On Wed, 2005-27-04 at 13:33 +0200, Alexander Larsson wrote:
> On Fri, 2005-04-22 at 16:20 +0200, Diego Gonzalez wrote:
> > Ok
> > 
> > here are my views on the difference of the three methods, included are
> > some of the reasons why i made this patch:
> > 
> > *) The typeahaed filtering only works in the list view mode, not in
> > the Icon View, my filtering patch works on both, also 
> > currently typeahead (that is, if i press Ctrl+F on the list view)
> > seems to be badly broken in HEAD, at least it doesn't
> > work for me.
> >
> > If (it doesn't work for me, so i can't be sure about this fact)
> > typeahead works in the same way as it works in the GtkTreeView it only
> > matches the string entered agains the start of files and directories.
> > 
> > The other feature with which you press the first letter of a file and
> > the view goes to the first file that starts with that letter
> > isn't enough most of the times (i'm talking about my particular use of
> > nautilus)
> 
> Eh? typeahead works fine in icon view. Just type the start of a filename
> and it'll jump to it. It is not limited to one character.
> 
> I'm not sure why the threeview-specific (ctrl-f) typeahead is broken
> though.
> 
> Its true that the typeahead is limited to searching at the start of the
> file, however that can easily be changed.

Perhaps he meant it doesn't work as nicely as the typeahead on gtk+
treeviews (ie the filechooser).
> 
> Also, we likely need a "next match" keybinding for the typeahead system.
> Someone on irc suggested ctrl-g, which is what most apps use for "find
> next".
> 
> > *) As this feature has to be explicitly activated, i mean, to use it
> > you have to press a button or a combination of keys and as the view
> > looses the filtering when closing a window or hidding the filtering
> > bar, I don't think it is that confusing as there is an explicit visual
> > feedback (that is the filtering bar) telling the user that the
> > contents of the directory are beeing filtered.
> 
> Yeah, that is true. (Although I think it should be made even more
> obvious that the window/view is filtered, and how to get out of that if
> possible.)

I think this would go well with the earlier ideas about using per folder
backgrounds and watermarks, perhaps a slightly shaded background is
sufficient.

 I see the filter as a modal view on the same data, only using sorting
as a spatial metaphor. Its all there there, you're just asking the
computer to rearrange the items as you like, with items you are not
interested be less likely to be visible. A filter throws files away, a
sort just puts them on the bottom.

<ui-details can-skip-this=true>
This overlaps with existing "Arrange Items" features, but is more
informative about what has happened to your data, and has a unified UI.

The UI I see is a menu toggle entry in View called "Sort Bar", which
causes a bar on the top or bottom that says "Sort [manually]" (where []
is a combo box), and a close button a la firefox's Tab and Find close
buttons, to appear. In the combo box there are entries like "by File
Type", "by File Name", etc.

Pressing the close button returns us to normal nautilus behaviour.
Choosing "by File Name" causes an Entry to appear that allows you to
specify a filter.

When a sort is activated from the sort bar, nautilus stacks the files in
order, with clear text demarking how it sorted. For example, all
matching files will be labeled as "Matching Files", and remaining files
will be labeled as "Remaining Files".

Sorting by files type would list types in alphabetical order, with
clearly marked "PNG (Image) File Types", etc.
</ui-details>

> 
> Some behavioural questions:
> * What happens with your selection when you filter? Say you have
> something selected, and then you filter so that item is not visible,
> then you delete. Is the file deleted?

The filter is applied, but the previously selected item is scrolled into
view. If the files are sorted according to the filter, then nothing ever
disappears, just moves.

> * Same with selection changes when filtering. Is select by
> pattern/select all limited by the filter?

Selection shouldn't change (although it'd move about). I think the
filter should replace the pattern select.

> * What happens if you create a new folder/templated file or copy a file
> into a filtered view. If we do nothing, the new (say "untitled folder")
> file won't be visible until you remove the filter (not letting you
> rename the folder), which is sort of strange. Another perhaps surprising
> behaviour (or perhaps not) is when you rename a file and it disappears
> (because it was filtered out).

If the data is sorted not filtered it should never disappear, just move.

> * How does filtering work in manual arrangement mode. Do we keep the
> positions, leading to lots of empty space? I guess one could say you
> just shouldn't use this mode with filtering. But it leads to the
> question, do we allow filtering on the desktop?

Sorting by file name, and sorting manually are mutually exclusive, so
this problem wouldn't exist.

My 2 cents.

Cheers,
Ryan