File Chooser Dialog [$170]

[Danielle Foré]

GTK's open file dialog is really ugly. We should make our own super sexy one as a part of Granite.

[Fabio Zaramella (fabiozaramella)]

Please make the mockup above real

[ClassicalBadger (idiotjoy)]

Forgive my ignorance. How does one contribute to a bounty? The open file dialog is easily the worst vestige remaining in Elementary OS (especially since a user must interact with it multiple times per day), and I can spare $15.

[Cody Garver (codygarver)]

Search for the bug URL on bountysource,
https://www.bountysource.com/issues/922290-open-file-dialog-15

On Thu, Feb 6, 2014 at 6:38 AM, ClassicalBadger <email address hidden> wrote:

> Forgive my ignorance. How does one contribute to a bounty? The open file
> dialog is easily the worst vestige remaining in Elementary OS
> (especially since a user must interact with it multiple times per day),
> and I can spare $15.
>
> --
> You received this bug notification because you are subscribed to
> Granite.
> Matching subscriptions: granite
> https://bugs.launchpad.net/bugs/1171650
>
> Title:
> Open File Dialog [$15]
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/granite/+bug/1171650/+subscriptions
>

--
Cody Garver

[Cassidy James Blaede (cassidyjames)]

There's now $80 in bounties.

[Cameron Norman (cameronnemo)]

A good way to accomplish this without patching gtk is to make the open file dialog a dbus service that returns a file, and then patch elementary applications to use it. The benefits of this approach could be expounded by GNOME (and other environments) also providing an implementation of the file chooser, and therefore GNOME and elementary applications would use the environment's implementation and remain consistent. Does that make sense?

[ClassicalBadger (idiotjoy)]

So if I'm reading this right, any applications that have not been specifically patched to support this dbus solution would still use the standard GTK dialog. If that is the case, then that could lead to an awful lot of confusion. I think presenting the user with two dialogs that look and function differently at (from the user's perspective) arbitrary points would be worse than just leaving the current GTK dialog where it is.

[oblv (oblv1)]

and what about save file dialog?

[Victor Martinez (victored)]

I've been working on this during the last couple of days, and there are some things we should consider before spending our resources on this:

1. This adds a source of inconsistency across GTK+ apps, unless GTK+ is patched.

At the desktop level, we already face the inconsistency that exists between old apps that still use GTK+ 2 and other apps already using a GTK+ 3.x.

Now, even applications using GTK+ 3 can look inconsistent by not using GtkHeaderBar (client-side decorations).

The current open/save dialog (GtkFileChooserDialog) is implemented in such a way that each app creates a new instance of the dialog, and then shows it to the user. Just like creating any other child window (e.g. a preferences dialog, etc).

Thus if we were to provide a Granite implementation, each app would have to be patched or modified to create a Granite File Chooser instead (see point 2 for more information on this), and apps not using Granite would still show the default GTK+ file chooser.

At the moment, the only way to override the open/save dialog accross ALL GTK 3 applications (without patching any application) is by modifying the implementation of GtkFileChooserDialog in GTK+ (without touching the public API). This would require patching the library itself, and modifying some widgets to be more elementary-ish. Of course, it is a ton of work, but not a lot more than the other solutions available.

2. Providing a Granite implementation, in spite of inconsistency across GTK+ 3 apps is possible. Two basic approaches have been considered so far:

2.1 Exposing the File Chooser as a DBus service (suggested by Cameron Norman in comment #6).

* This could be implemented in Pantheon Files, so that it provides the file chooser as a DBus service. The good thing about this approach is that the actual implementation would live outside Granite, meaning there would be no need to move widget implementations into Granite, which usually implies a lot of rewriting and restructuring (we are speaking about the sidebar, pathbar, and file browser icon and list views).

* A wrapper API could be provided in Granite, so that apps don't actually have to deal with DBus (just like we do in ContractorProxy).

Some issues with this approach:

* The FileChooserDialog is usually required to be modal and block any other interaction until the user either cancels or selects a file. If the implementation is provided by another application, this would involve some window-manager trickery, and there doesn't appear to be a reliable way to steal focus from the main window. Example: https://bugs.launchpad.net/policykit-1-gnome/+bug/433851/comments/4

* There could be visual integration issues. For example, an application that is using the dark theme would have to let the application providing the File Chooser know about it via DBus, so it can use the proper style.

* The DBus API would have to be extensive to stay on par with GtkFileChooserDialog. An acceptable replacement would have to provide all the facilities exposed by GtkFileChooser. See https://developer.gnome.org/gtk3/3.12/GtkFileChooser.html

* A lot of plumbing is needed in files to implement this in a clean way without duplicating...

[Danielle Foré (danrabbit)]

It looks like William Jon McCann is doing some work on GtkFileChooser upstream. We have to find out what exactly their plans are. It's possible that this work could be done mostly there. So for now, we're postponing until we get some more info about what's going on in Gtk.

[Yosef Or Boczko (yoseforb)]

I added two screenshot from gtk+ git master, with the last change in the
GtkFileChooserDialog widget.
I think this isn't the end of the changes (see the mockup from mccan in the
original bug).

[Danielle Foré (danrabbit)]

I'm uploading here a recent screenshot of Gtk.FileChooser as it is in Gtk 3.13. Using this as a baseline, it means we have the following issues in order to get this design more like our design:

* When not using actions in the headerbar (dconf option), Put the pathbar in the headerbar. Also add the file type filter selection combobox thingy to the action area (currently it appears above it which is why in this screenshot you don't see a top border on the action area)

* Add the grid (icons/thumbnails/whatever) view

* Add forward and back buttons

* Add categories to the source list

* Make the pathbar work like Pantheon Files.

* Miller columns (not in the mock but would be really really nice)

Of these, probably the easiest to upstream and biggest impact changes would be the first thing about where stuff goes when you're not using actions in the headerbar.

I think we might have to make some concessions about certain designs such as the grid view not being exactly the same as Files and without a lot of work we probably can't have the same pathbar as Files.

Something that might be more difficult is we have to find out why they decided not to use categories or present forward/back navigation. Adding views like grid and column would also probably be a lot of work and face design scrutiny. I wonder if it's possible to have views be pluggable somehow so that distributors can add/remove their own views? This would allow us to circumvent design disagreements in the views at least.

[Corentin Noël (tintou)]

If someone is interested by this bug, here is how I think this should be done until the FileChooserDialog got more abstracted upstream.
I managed to build a Gtk3 module that detects every Gtk.FileChooserDialog opening, so the remaining work is to implement the same UI as Pantheon Files.
I think that this module should be a part of files allowing people to have this FileChooserDialog if they use Pantheon Files.
( https://code.launchpad.net/~tintou/pantheon-files/gtk-module )
for testing, just append "GTK_MODULES=pantheon-files-module" before running an app.
for example GTK_MODULES=pantheon-files-module noise

Then making Pantheon Files as a default app can add the module name in the org.gnome.settings-daemon.plugins.xsettings.enabled-gtk-modules DConf entry.

[Danielle Foré (danrabbit)]

Based on Corentin's work/research here I think shipping a Gtk Module with Files is probably the best solution. It would keep us from having to modify other apps. So I'm going to confirm for Files and remove Granite.

[Adam Bieńkowski (donadigo)]

I did some experiments and I came up with this... Still I need to find the way to remove the old pathbar and connect buttons to actions. The initial functionality of pathbar is implemented already...

[quequotion (quequotion)]

How is this coming along?

I've built and installed the bzr, and added "pantheon-filechooser" to gtk-modules, but I only get the ususal GTK filechooser in apps.

Am I missing something?

[quequotion (quequotion)]

Oh no, it works! I just didn't recognize it.

http://postimg.org/image/94s47spfb/

Nice filechooser!

What do you think about making a gtk2 port (for third party apps still using gtk2)?

[quequotion (quequotion)]

Had to edit that screenshot:
http://postimg.org/image/e173h2fex/

[quequotion (quequotion)]

>>20

I edited the photo to remove my username.

In pantheon files, home is represented by a home icon breadcrumb with no username.

Could the filechooser dialogs do the same?

[Ash (ash1991)]

The file chooser dialog still has two bugs:

1. The bookmark pane is not pantheon-files like(it's more nautilus like)
2. Reload icon isn't shown from the beginning in the pathbar(the icon on rightmost side)

[Danielle Foré (danrabbit)]

@Ash, please file these as new issues against Files