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 312532 - GtkFileChooserIface is private
GtkFileChooserIface is private
Status: RESOLVED DUPLICATE of bug 382528
Product: gtk+
Classification: Platform
Component: Documentation
2.6.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2005-08-04 05:38 UTC by Yevgen Muntyan
Modified: 2007-05-04 19:43 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Yevgen Muntyan 2005-08-04 05:38:47 UTC
Version details: 2.6.4
Distribution/Version: Debian Stable

GtkFileChooserIface is private, so it's impossible to implement this  
interface. Either it should be public, to allow custom implementations, or the  
docs should be corrected, since they say:  
"GtkFileChooser is an interface that can be implemented by file selection  
widgets. In GTK+, the main objects that implement this interface are  
GtkFileChooserWidget, GtkFileChooserDialog, and GtkFileChooserButton. You do  
not need to write an object that implements the GtkFileChooser interface  
unless you are trying to adapt an existing file selector to expose a standard  
programming interface." 
Specifically, it should say that "You may not write an object that implements 
the GtkFileChooser interface". 
  
Use case: In my program I need a treeview widget which displays files and  
folders, pretty much the same as the treeview in GtkFileChooser. I can't use  
GtkFileChooserWidget since I get also bookmarks for free and I do not have any  
control over it, so I need to write my custom one. I thought I could use  
GtkFileChooser interface to make my task easier and to keep api more  
consistent.
Comment 1 Owen Taylor 2005-08-04 13:51:13 UTC
GtkFileChooser still isn't to the point where we'd want to have to
maintain ABI compat for its virtual functions.

I have no idea what the sentence

"unless you are trying to adapt an existing file selector to expose a standard  
programming interface." 

was supposed to mean. It certainly needs fixing.
Comment 2 Todd Denniston 2005-08-05 00:55:51 UTC
Although I am using gtk+-2.0 on Fedora Core 3, I believe I am having the
same/similar trouble to muntyan.

The use case is:
I need the application to trap/keep the users in the directory tree of only one
system subdirectory.

The problem:
gtk_file_chooser_list_shortcut_folders and
gtk_file_chooser_remove_shortcut_folder can not get a handle on the (gtk Built
in) shortcuts of "Home", "Desktop" and "Filesystem", so that I could then use
gtk_file_chooser_add_shortcut_folder to give them access to the one subdirectory
tree I want them in. Because ".." is not listed in the dialog, I believe if I
can start them out there and not give them the three builtins I would be good to go.

Federico Mena Quintero gives good details on the desire here:
http://primates.ximian.com/~federico/docs/file-chooser-extension-spec/#scenario-lockdown
But I have been unable to find details for implementing such with the now
implemented GtkFileChooser, searching the fine web.
Comment 3 Murray Cumming 2007-05-04 19:43:31 UTC

*** This bug has been marked as a duplicate of 382528 ***