[Webkit-unassigned] [Bug 169278] New: [GTK] Use GtkFileChooserNative for open/save dialogs

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=169278

            Bug ID: 169278
           Summary: [GTK] Use GtkFileChooserNative for open/save dialogs
    Classification: Unclassified
           Product: WebKit
           Version: Other
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKit Gtk
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: aperez at igalia.com
                CC: bugs-noreply at webkitgtk.org

Starting with GTK+ 3.20 there is a new GtkFileChooserNative file chooser
dialog implementation:

  https://developer.gnome.org/gtk3/stable/gtk3-GtkFileChooserNative.html

It would be interesting to use it if possible, when building with GTK+ 3.20+
because it allows for a few niceties which better integrate applications
using WebKitGTK+ into the running environment:

 - When an application is running on a desktop environment which does not
   use GTK+, the desktop environment could set up things to use its native
   open/save dialogs (e.g. the Epiphany running on KDE could use Qt dialogs).

 - When an application is running inside a sandboxed environment (for example
   with Flatpak — http://flatpak.org), “portals” may be used automatically
   to allow for selection of files from outside of the sandboxed environment.

 - Using platform-specific open/save dialogs where available (e.g. in Mac OS;
   at the moment it is not possible to build a recent WebKitGTK+ for Windows,
   but the code would be ready to use Windows systems dialogs if somebody
   would add the other missing pieces).

Note that GtkFileChooserNative has a few shortcomings when compared to
GtkFileChooserDialog, so part of the work is to evaluate whether the current
uses of the latter can be replaced with GtkFileChooserNative.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170307/a5d5e9e9/attachment.html>