Re: RFC: On-line Content Filtering of directories

[lhervier free fr]

> 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.
>
> 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.)
>
> My main concern is trying to limit the amount of overlapping features,
> so that each addition of a feature adds something important over the
> existing ones. Each overlapping feature increase complexity, make the UI
> harder to understand/more crowded and increase maintenance costs.
>
> What are the ways we can make this more obvious to the user?
> Here are some ideas:

We can imagine displaying filtered content as "grayed" or "transparent". Like
this, the views will always display the whole content, but for the users, the
selected part will seems "highlighted". I don't know how to describe it
precisely in English, but a good example is the way Windows display hidden
folders.

Think of it as a selection that users won't loose when they click or
select a specific item.

We may also always display the selected items on top of the list (except when in
manual arrangement mode), using the view's sort order. We may also leave some
space between the two parts.

Using some tricks like "Edit -> invert filter", we may also merge the "select
*these* files" and "do not select *these* files" features (ok, the second one
will need one more action). And ok, as we don't have an "Edit -> Invert
selection", i suppose we may not want this...

> * Have a remove button in the filtering bar, similar to the one firefox
> has in its search bar.
Agree. But we may also have "Edit -> Remove filter", "Edit -> Filter files based
on pattern", and so making this feature available in normal mode. (again, doing
a parallel with the selection feature).

> * Perhaps make it more obvious that the filter is on the name, by having
> "name" somewhere on the filter bar. (Do we want to filter on other
> fields too btw? say type, or owner)
I think that filtering must be a limited functionnality. I often search for
files based on their content, but for such advanced functionnalities, i prefer
using tools like Beagle. So, for me, filtering must only be on files names
(again, like selection).

> * Sometimes you might not see the whole window, or just not look at the
> bottom. Maybe we could figure out some other (additional) way to say
> that this is a filtered view that is visible in the whole window, or at
> least in more places. Maybe we can use colors? background color? some
> sort of border around the view? different window title?
The user will see that this is a filtered view as icons corresponding to
filtered items will be displayed in a different way. But adding a label in the
title bar may be a good thing.

> * The status bar should perhaps say something like "3 items (of 28)" to
> make it obvious the count is of the filtered items
Agree.

>
> Also:
> * Need a mnemonic on the filter label
> * I think ctrl-g might be more useful for "next typeahead match" than
> for filtering. We should pick a different accelerator.
>
> 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 items will still be selected, so the files will be deleted. We may add a
warning in the confirmation message box when trying to delete a file that is not
in the unfiltered part of the view.

> * Same with selection changes when filtering. Is select by
> pattern/select all limited by the filter?
Same thing here. Items will still be selected.

> * 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).
The folder no longer disappears, but it will not be highlighted until renamed to
a matching name.

> * 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?
Here, we may just not change the display order, but still highlight unfiltered
content.

>
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  Alexander Larsson                                            Red Hat, Inc
>                    alexl redhat com    alla lysator liu se
> He's a benighted dishevelled werewolf possessed of the uncanny powers of an
> insect. She's a violent tempestuous bodyguard from out of town. They fight
> crime!
>
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
>
>

Some issues:
- As all the items are displayed, should typeahead match work only in the
selected part ?
- What does "select all" means ? Select only unfiltered content or really select
all items ?

I'm not a GTK developper, so these are just some ideas...

Lionel