Re: RFC: On-line Content Filtering of directories

[Alexander Larsson <alexl redhat com>]

On Wed, 2005-04-27 at 15:11 +0200, Maciej Katafiasz wrote:
> Dnia 27-04-2005, śro o godzinie 13:33 +0200, Alexander Larsson napisał:
> > 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".
> 
> Errr. Let me remind you that C-g is emacs' universal "cancel" key,
> particularly cancel incremental search. Binding it to "next match" is
> like punch in the face for any emacser, and I repeatedly hate gecko for
> doing that to me :>

I refuse to let the bizzare interface of some ancient editor affect the
design of a modern desktop (and I'm a emacs user). C-g is "find next
match" in most modern UIs, end of story.

> > 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.)
> 
> We could also use background colours (as you suggest below), and for
> colourblind users, also embed emblem in the background.

The listview is a bit problematic here though.

> > 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. 
> 
> The question is, is it worthy at all to keep glob selection in presence
> of filtered view? I'd say we just make it automagically switch into glob
> mode when any of * or ? is entered, and forget about today's glob
> selection.

I'm not sure what glob mode is? 

Glob selection has none of the problems that filtering has, because glob
select doesn't add any new persistent concepts. All it does is add a
method for quickly selecting a set of files you could manually have
selected. Any feature, like filtering, that introduces a new concept
that is persistent in the interface however, interacts with *all* other
features in the whole application. Witness for instance how the
filtering concepts interact with the current folder selection concepts
in sometimes confusing and complicated ways. It will also interact with
and limite all future features additions. This is why I worry about
things like this.


> > 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.
> 
> Firefox uses C-k, and it is (IMHO) rather fine choice, and gets us bonus
> points for being consistent with FF. (I guess C-k is it because it's
> right next to C-l, mnemonic for location bar. Which would work according
> to the same logic for browser windows, and shouldn't hurt for spatial
> ones)

Ctrl-k goes to the google field for me, whereas the more filter-like
find bar is triggered by Ctrl-F (which is used by the tree view
typeahead).

> > 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?
> 
> Definitely not.

So, the selection is changed by applying a filter then? This is
certainly a complication of the user model of the "current selection". I
agree that deleting a file that you didn't see is horribly bad, but this
leads to a redefinition of what the current selection is and how it
works. For instance is the file re-selected when you cancel the filter?

> > * Same with selection changes when filtering. Is select by
> > pattern/select all limited by the filter?
> 
> Of course. Question is if that change is transient, ie. if user selects,
> then filters, then unfilters without changing selection, do we revert to
> original selection, or rather stay with filtered one? I'd weight more
> towards transient interpretation, but then it may clash with previous
> point, that is, it may be not obvious to the user what happens if she
> selects, filters, and then hits Delete.

Exactly. Neither option is perfect...

> > * 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 that happens, simply cancel the filter.

Cancelling the filter whenever something changes is certainly an option.
I'm not sure its all that nice though. It means you can't really do much
work in the filtered view. Cancelling only when a change affected an
filtered file would make this more useful, but its suddenly no longer
obvious when the filter is cancelled. 

I guess read-only use of filtering isn't affected, but it seems harder
to make read-write use of a filtered view work well.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's an underprivileged flyboy senator on a search for his missing sister. 
She's a beautiful mute Valkyrie with an MBA from Harvard. They fight crime!