Re: GtkFileChooser extensions
- From: Alex Graveley <alex beatniksoftware com>
- To: Fernando Herrera <fherrera onirica com>
- Cc: Federico Mena Quintero <federico ximian com>, GTK+ development mailing list <gtk-devel-list gnome org>, trow ximian com, dashboard-hackers gnome org, GNOME Desktop <desktop-devel-list gnome org>
- Subject: Re: GtkFileChooser extensions
- Date: Wed, 22 Sep 2004 17:47:37 -0400
Thought I add a few interesting use cases off the top of my head...
- Searching for "pictures from naples" should show me photos and maybe
their categories, not just the meaningless name my camera gave it.
- Searching for "joe email" should be able to show me attachments joe
has sent me in email that I haven't saved anywhere yet. It may also
display the title of the email it was sent in.
- Searching for "polymorphic type system" should be able to show me the
pdf document I browsed online, but which either doesn't exist on the
filesystem or has been automatically put in some temp directory.
- Searching for "kid a" should display my music from that album and the
artist's name and track title.
There are a million more, but representing them all in the existing
file-chooser treeview is going to be difficult while still making them
useful to the way the user thinks about a file's origin and meaning.
On Wed, 2004-09-22 at 17:07, Alex Graveley wrote:
> I'm wondering if the best way to convey search context is by showing
> Tiles, as would appear in Best. Search results may encompass weird
> connections between terms and results, and I think the Tile UI will end
> up being the way that those connections are made useful and
> understandable to the user.
> So is it a good idea to make the extension spec robust enough to handle
> setting an arbitrary main file-list widget?
> On Wed, 2004-09-22 at 14:15, Fernando Herrera wrote:
> > El mié, 22-09-2004 a las 10:25 -0500, Federico Mena Quintero escribió:
> > > I've been working on a specification for an extension mechanism for
> > > GtkFileChooser. Global searching, lock-down, and metadata systems would
> > > benefit from being able to extend what GtkFileChooser can do.
> > >
> > > The draft spec is here:
> > >
> > > http://primates.ximian.com/~federico/docs/file-chooser-extension-spec/index.html
> > Really cool!. About the search stuff on the filechooser, I was talking
> > with someone about it, and we realized that, for files, context is
> > really important. Thing about searching a picture of "Lucas" typying
> > "lucas" and presenting results as normal files in the file view. It
> > would ne like:
> > * Lucas.jpg
> > * 1002.jpg
> > * IMG234.jpg
> > [...]
> > But maybe the user would like to know their context:
> > * /media/pictures/Lucas - Ribiera Concert/1002.jpg
> > * /media/pictures/partys/Fiesta en casa de Lucas/Lucas.jpg
> > * /home/fer/Desktop/crazy lucas/IMG234.jpg
> > so that's because I used clarkbw Find UI  in my quick-and-dirty-only-
> > for-me GtkFileChooser search hack 
> > So I don't know if gtk_file_chooser_set_extra_widget_for_extension() is
> > flexible enough for adding the widget in the right place (as seen in 
> > it is over the file list for the open dialog)
> > Salu2
> > --
> > : http://www.gnome.org/~clarkbw/blog/GNOME/finding_a_good_find
> > :
> > http://www.gnome.org/~fherrera/blog/searching_inside_the_GtkFileChooser.html
> > : http://primates.ximian.com/~federico/docs/file-chooser-extension-
> > spec/open-with-search-results.png
> > _______________________________________________
> > Dashboard-hackers mailing list
> > Dashboard-hackers gnome org
> > http://mail.gnome.org/mailman/listinfo/dashboard-hackers
> desktop-devel-list mailing list
> desktop-devel-list gnome org
] [Thread Prev