After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 382528 - Unable to implement custom filechoosers
Unable to implement custom filechoosers
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
2.10.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
Federico Mena Quintero
filechooser-design-needed
: 312532 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-12-05 08:40 UTC by Tommi Komulainen
Modified: 2015-07-07 04:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Tommi Komulainen 2006-12-05 08:40:35 UTC 
Currently the GtkFileChooserIface struct is private, the header declaring it is never installed, which makes it impossible (or at least impractical) to write custom GtkFileChooser implementations.

I think it would be perfectly acceptable to label the implementation API unstable (similar to GtkFileSystem) as long as the necessary headers are installed and functions exported to enable implementing a GtkFileChooser out of gtk code tree.

On related note, it would probably be a good idea to *not* include GtkFileSystem in the GtkFileChooserIface API as it ties all implementations to the GtkFileSystem abstractions and complicates things like using gnome-vfs directly (for better control) and allowing access to in-memory "file system". Rather the interface should map to the public filechooser functions.
Comment 1 Owen Taylor 2006-12-05 14:18:53 UTC 
Responding only to:

> On related note, it would probably be a good idea to *not* include
> GtkFileSystem in the GtkFileChooserIface API as it ties all implementations to
> the GtkFileSystem abstractions and complicates things like using gnome-vfs
> directly (for better control) and allowing access to in-memory "file system".
> Rather the interface should map to the public filechooser functions.

The point of doing so is to avoid having to have every function in 
URL / filename pairs, and instead use GtkFilePath. This design keeps
the GtkFileChooser interface much more compact (and easier
to implement) than it would be otherwise. Since the GtkFileChooser
interface functions in GTK+ are chained through:

 GtkFileChooserDialog
 GtkFileChooserWidget
 GtkFileChooserDefault

(Not to mention GtkFileChooserButton), the savings add up.

If you were so inspired you could implement a dummy GtkFileSystem that
only implemented the GtkFilePath mapping functions and nothing else.
Comment 2 Tommi Komulainen 2006-12-07 19:36:46 UTC 
(In reply to comment #1)

That is a good point. It does make GtkFileChooser and GtkFileSystem(+ related items) pretty tightly coupled, though I'm not sure if that is a real problem.
Comment 3 Murray Cumming 2007-05-04 19:43:31 UTC 
*** Bug 312532 has been marked as a duplicate of this bug. ***
Comment 4 Matthias Clasen 2015-07-07 04:45:26 UTC 
I think it is time to retire this requets.