Filechooser: hide file browser by default in save dialogs

[hanaral]

Problem

99% of users will just save the file to their Documents folder or to a bookmarked location. If a user wants to save a file, any file, they are met with a worse version of the normal file browser. This is visual bloat and confusing for users, since it brings the user's entire app-workflow to a grinding halt as it opens something that resembles a seperate app and likely obscures the entire underlying window. There is also the issue of the file saving dialogue not feeling completely native, since it is retrofitted on to the normal gtk.filechooser-dialogue afaik Edit: looking at the new FileChooser tells me otherwise, but it also demonstrates how the filechooser looks similar to the actual Files app but uses an entirely different sidebar

Proposal

Elementary OS should have it's own file saving dialogue box, which has a name entry box at the top, a drop down with the users default and bookmarked locations. MacOS handles this in this exact way (at least it used to)

This should also solve the issue of not having a fully-native filechooser dialogue

Prior Art

How macOS 10.4 handled it is a really good example. Default size: Expanded size:

I'd love to hear what elementary/us think!

[pongloongyeat]

I believe this is being worked on (see files/filechooser-portal)

[hanaral]

I've tested it and I'm not seeing much of an improvement. As in my original comment, the window is far too large and the operation that the user is partaking in is not that complicated, so there is no reason to have such a complicated dialogue. I understand that people can't work for free, so I'd be happy to put a $15 bounty on it if any of the files team is interested. Tagging @tintou since I don't quite understand the current FileChooser situation - would it be possible to implement something similar to my proposal?

[danirabbit]

It sounds like the suggestion here is to have the browser part of the save version of the file chooser dialog collapsed by default and replaced by a simpler combobox chooser, based on the assumption that typically users will save files in a top level bookmarked directory.

I don't really have a strong opinion on this. It could be an interesting idea to try

[pongloongyeat]

Ahh sorry for my poorly written reply then. I misread it as FileChooser looking like it's not part of eOS (I read it at 4am my bad).

I think this a great idea! I really like how the MacOS's FileChooser only exposes folders in the home directory (or it seems that way in the screenshot). In a way this makes people less scared since there's no worry of saving stuff to a system-related area (the file system for instance).

In fact, wouldn't it be a good idea to just expose the folders in the home directory to users? Your typical everyday user doesn't need to access the whole file system /, usually just /home. If this is the case then the "File System" button in Devices can instead be renamed to the user's username and point to the Home folder. If someone truly needed to access the file system they can type / in the address bar.

[hanaral]

In fact, wouldn't it be a good idea to just expose the folders in the home directory to users? Your typical everyday user doesn't need to access the whole file system /, usually just /home. If this is the case then the "File System" button in Devices can instead be renamed to the user's username and point to the Home folder. If someone truly needed to access the file system they can type / in the address bar.

I think the point of the Files app intentionally having these features is due to power users, at the end of the day it is still just a file browser, hence why it hasn't got a colourful app icon. My dissatisfaction is only with the filechooser dialogue, since the average user shouldn't optimally have to manage files from it's own app.