Re: RFC: On-line Content Filtering of directories

[diego pemas net]

> 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.

Ok, as i see it this is possible in the icon view, but the list view
doesn't support any kind of background.


>  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.
>
I have already put a close button on the filtering bar, but i can't send
it as i'm away for the weekend.

> 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".

I really don't like mixing files that match the filter with the files that
didn't although I wouldn't be oppossed if we could find a gooed enough way
in which to show the differece between the two groups of files, remember
that this has to be implementable (I also can't put a lot of time into
this, as my final examns are approaching rapidly).

Providing visual clue of a filtered window should be easy in Icon View
(even if using a slightly shaded background), in the List View it is a lot
more difficult (at least with my knowledge about the GtkTreeView widget).

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

This is pretty similar to what ETable/ETree can do groupings, I don't
think GtkTreeView has such a feature yet.

> </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
>
> --
> nautilus-list mailing list
> nautilus-list gnome org
> http://mail.gnome.org/mailman/listinfo/nautilus-list
>