GNOME Bugzilla – Bug 155729
Lock-down capability
Last modified: 2015-03-08 14:23:48 UTC
Our application needs the ability to customize the appearance of the file open/save dialog. For example, we restrict our users from opening/saving files in one particular directory, thus we need to hide widgets relating to directory changes. We currently use GtkFileSelection and gtk_widget_hide to hide the appropriate widgets. We would like to use GtkFileChooser, but realize its interface is purposefully opaque. What I would like to propose is the addition of some GtkFileChooser methods that facilitiate customization of the appearance / function of the dialog, e.g. gtk_file_chooser_tree_view_hide/show - this would include the top left box and the +/- buttons. This should effectively slide the left margin of the file view over to the left margin of the window. gtk_file_chooser_dir_buttons_hide/show - the buttons above the file view are not required if the user is not allowed to select a different directory. gtk_file_chooser_path_hide/show - when we restrict our users to a given directory, we don't want them to know what it is or give them any hints that the system is running a particular OS. The widget should hide/show any references to the real path to the current directory. GtkFileSelection, for example, shows the path next to the "Selection" label above the selectiont text. Details of this were discussed on the dev list 10/15 & 10/16/2004.
We really don't want to expose the internals of the file chooser in this way. If anything, we would add a new action like GTK_FILE_CHOOSER_SAVE_IN_FOLDER. But from your description, it sounds like it would be much easier for you to just show an entry for the user to enter the filename. What does using file chooser add in your use case ? Well, the user can see the existing files in the current directory, I guess...
*** Bug 155740 has been marked as a duplicate of this bug. ***
I had already considered rolling my own dialog(s), but ultimately concluded that by the time I provided the necessary functionality, less the folder-specific stuff, I'd have duplicated about 75% of GtkFileChooser. I don't want to reinvent the wheel when GtkFileChooser could (and should, IMHO) be modified to provide the necessary customization functionality. While I'll be the first to admit the manner in which I am customizing GtkFileSelection is inappropriate (direct access to pointers), it's because there's no API to do what I want. And, While I agree in principle with GtkFileChooser's API and the decision to hide the internals, I can't use it in its current form. For what it's worth, I'm not the only one modifying GtkFileSelection in this manner, and none of us would need to hack away at what should rightfully be private data if the API did what we wanted. Ultimately, I don't really care how it's implemented, so long as it's implemented -- particularly if GtkFileChooser is to eventually replace GtkFileSelection. I would prefer the flexibility in the API as I outlined, but if it simply provided an option to restrict the open/save operation to a single folder (and automatically disabled the parts of the dialog that didn't make sense in that mode), that would be okay too, and perhaps more in line with the goal to keep the internals opaque.
What you want is a lock-down framework that allows you to restrict the user to particular folder. I'm working on a specification for an extension mechanism for GtkFileChooser, and one of the things it contemplates is a lock-down system. Please read the draft spec here: http://primates.ximian.com/~federico/docs/file-chooser-extension-spec/index.html The discussion starts here: http://mail.gnome.org/archives/gtk-devel-list/2004-September/msg00072.html I'm retitling this bug for clarity.
4 years and nothing new... Someone asked me for this feature today. Are there plans for this before GTK 3.0 ?
No specific plans
clearly, nothing happening here