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 155729 - Lock-down capability
Lock-down capability
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
2.4.x
Other All
: Normal enhancement
: Medium API
Assigned To: gtk-bugs
Federico Mena Quintero
filechooser-design-needed
: 155740 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-10-18 14:35 UTC by Doug Vetter
Modified: 2015-03-08 14:23 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Doug Vetter 2004-10-18 14:35:36 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.
Comment 1 Matthias Clasen 2004-10-18 15:26:54 UTC
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...
Comment 2 Owen Taylor 2004-10-18 17:00:02 UTC
*** Bug 155740 has been marked as a duplicate of this bug. ***
Comment 3 Doug Vetter 2004-10-18 17:34:58 UTC
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.
Comment 4 Federico Mena Quintero 2004-10-22 14:12:19 UTC
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.
Comment 5 Luis Menina 2009-03-09 16:02:39 UTC
4 years and nothing new... Someone asked me for this feature today. Are there plans for this before GTK 3.0 ?
Comment 6 Matthias Clasen 2009-03-09 16:31:07 UTC
No specific plans
Comment 7 Matthias Clasen 2015-03-08 14:23:48 UTC
clearly, nothing happening here