Re: GtkFileChooser extensions

On Thu, 2004-09-23 at 18:55 -0500, Federico Mena Quintero wrote:
> 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.

The whole reason that GtkFileChooserWidget is a bin is to allow
alternate file chooser implementations to be dropped in without
modifying the publically exposed type or constructor. The default
implementation is a lot of code though, so reimplementing it isn't
all that appealing. Some of the pieces could presumably be exported.


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]