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