Re: GtkFileChooser extensions
- From: Federico Mena Quintero <federico ximian com>
- To: Havoc Pennington <hp redhat com>
- Cc: trow ximian com, dashboard-hackers gnome org, seth gnome org,	GTK+ development mailing list <gtk-devel-list gnome org>,	GNOME Desktop <desktop-devel-list gnome org>
- Subject: Re: GtkFileChooser extensions
- Date: Thu, 23 Sep 2004 18:55:38 -0500
On Wed, 2004-09-22 at 17:19 -0400, Havoc Pennington wrote:
> Have you given some thought to the pros and cons of the two obvious
> alternate approaches:
> 
>  1. allow wholesale replacement of the file chooser without modifying 
>     gtk (also enables the "we want one that looks just like windows" 
>     crowd)
That was the original idea behind making GtkFileChooser an abstract
interface ;)
How do we deal with GtkFileChooserDialog, however?  That one *is* a
GtkDialog that embeds a GtkFileChooserWidget, which in turn is a bin
that contains an opaque GtkFileChooserDefault implementation.
I guess most apps use GtkFileChooserDialog, and they wouldn't be happy
about changing their code to use some other object which happens to
implement the GtkFileChooser interface.  They also want a GtkDialog-like
interface to do gtk_dialog_run() and such.
>  2. just add the three features you mention (search, metadata, 
>     filtering) to the default file chooser
This would probably give us a good UI in the beginning, and then it
would get obsolete really soon.  We wouldn't be able to change the API
then.  I guess an extension mechanism can delay obsolescence a bit.
> I would be curious about those options. The worst of all worlds it seems
> to me is that you do an extension interface that turns out to be only
> useful for these three features, then you have a set of ABI/UI
> limitations that are hardcoded, without real gain. Of course, it's tough
> to answer the question "are there future extensions we'll want, and if
> so what are they, and what extension points will they require"
Yeah, it's hard to know what we'll need in the future.
I could only think of one other interesting extension:  Recent Files.
You could implement it in a similar fashion to the searching stuff; you
put in a "Recent Files" shortcut, which displays the recent-files list
when activated.
> I think Bryan and Seth have given some thought to search UI for the
> filesel, so pestering them until they fork it over might also be smart.
Bryan, Seth, did you read this? ;)
  Federico
[
Date Prev][
Date Next]   [
Thread Prev][
Thread Next]   
[
Thread Index]
[
Date Index]
[
Author Index]