Bug 14760 – [Gtk] Using GtkFilerChooserButton for html file controls

• Component: WebKitGTK
• Status: RESOLVED WONTFIX

[Christian Dywan]

Gtk has a special widget which should be used wherever a file is to be selected by the user. It's the GtkFileChooserButton, see here for details:

http://developer.gnome.org/doc/API/2.0/gtk/GtkFileChooserButton.html

The Gdk (Gtk) port of WebKit should use it to for html file inputs.

[Jan Alonzo]

Hi! Are you suggesting that we should use GtkFileChooserButton instead of the standard "Browse" button/file input text field combination? GtkFileChooserButton embeds the filename within the widget and having a GtkFileChooserButton + file input text field would be redundant.

Also, developers will probably expect to have a file input field there and might be surprised if a GtkFileChooserButton is used. Issues like how do you get the filename on POST will come up.

[Christian Dywan]

(In reply to comment #1)
> Hi! Are you suggesting that we should use GtkFileChooserButton instead of the
> standard "Browse" button/file input text field combination?
> GtkFileChooserButton embeds the filename within the widget and having a
> GtkFileChooserButton + file input text field would be redundant.
> 
> Also, developers will probably expect to have a file input field there and
> might be surprised if a GtkFileChooserButton is used. Issues like how do you
> get the filename on POST will come up.

Yes, I am suggesting to use a GtkFileChooserButton as a file control and nothing else. I don't see why anyone would be confused. This is the Gtk port, so controls are represented by Gtk widgets.

[Luca Bruno]

I think it's not quite possible.
To achieve this the gtk port would change how these things are handled. In other words, instead of having an input box for the file and a button for browsing, we would have only one button, and this painful for the layout.

For instance, imagine the html does put the file input and the browse button not adiacent, but one up and one down. Could you suggest a way to solve this problem without changing the layout?

[Christian Dywan]

In fact in HTML this is only one element, which is specified like so: <input type="file"> So the question is: Do webdesigners usually expect a certain size for that element or a certain layout behavior? If we were to use a native widget this would look like only one element in contrast to the usual button with a textfield or label next to it.

[Christian Dywan]

Created attachment 17744 [details]
Comparision of "file" control represantations

This is an image showing a GtkFileChooserButton, a "file" control in Firefox and a "file" control in Opera.

[Sven Herzberg]

Well, webkit's representation already looks different from Opera/Mozilla. So why not go one step further and make a file selection input field look the same as in all the other GTK+ based apps?

[Adam Roben (:aroben)]

Created attachment 17751 [details]
<input type=file> in Safari

For comparison, here's how <input type=file> looks in Safari.

[Luca Bruno]

Well, i'm going to agree.

[Mathias Hasselmann]

Yes, GtkFileChooserButton looks much better, but it has one serious limitation (IMHO): It doesn't support copy-and-paste. As developer I quite often already have the full path of the file I am going to upload. Browsing trough the file system is quite annoying in such a situation.

[Martin Robinson]

I think we should stick with the WebKit look for now. Perhaps we can talk about this again if someone is willing to implement it.