Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Save" and "Open" dialogs are not independent #671

Open
leonidasv opened this issue Oct 19, 2018 · 8 comments
Open

"Save" and "Open" dialogs are not independent #671

leonidasv opened this issue Oct 19, 2018 · 8 comments
Labels

Comments

@leonidasv
Copy link

@leonidasv leonidasv commented Oct 19, 2018

I noticed the "Save File" and the "Open File", at least on Chrome, are behaving in a "shared" state.

For example, if a webpage asks me to open a file, and I browse to /home/me/xx/yy directory to pick that file, when I click to "save as" another file (from the same or from another webpage) the dialog will ask me to save the file on that directory.

On the same way, if I save a file to /home/me/Downloads, when I click to upload a file on the browser, the dialog will put me on the same /home/me/Downloads directory.

The OPEN and the SAVE dialogs should have independent histories, since saved files mostly goes to ~/Downloads and opened files are hardly picked from ~/Downloads. Every other major distro/desktop environment has this split behavior for saving and opening files.


Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@jeremypw

This comment has been minimized.

Copy link
Collaborator

@jeremypw jeremypw commented Oct 20, 2018

At the moment there is a single "last-folder-uri" setting for the filechooser. We could have two settings instead. However, applications should be able to override this setting when they use the chooser, I think.

The native Gtk filechooser has only one last folder setting as well so I am not sure how other distros implement this.

@jeremypw

This comment has been minimized.

Copy link
Collaborator

@jeremypw jeremypw commented Oct 20, 2018

Note the following from Gtk documentation:

"Note that old versions of the file chooser’s documentation suggested using gtk_file_chooser_set_current_folder() in various situations, with the intention of letting the application suggest a reasonable default folder. This is no longer considered to be a good policy, as now the file chooser is able to make good suggestions on its own. In general, you should only cause the file chooser to show a specific folder when it is appropriate to use gtk_file_chooser_set_filename(), i.e. when you are doing a Save As command and you already have a file saved somewhere."

I am not sure what "make good suggestions on its own" means - it generally seems to show the last folder navigated to and using set_current_folder_uri () seems to be ignored if used before running the dialog. It should be possible for the custom elementary version of the Gtk dialog to override this though.

@leonidasv

This comment has been minimized.

Copy link
Author

@leonidasv leonidasv commented Oct 21, 2018

Gnome at least seems to implement different folder settings for the Save and Open dialogs. It may be worth taking a look at its implementation of this feature.

@mcclurgm

This comment has been minimized.

Copy link
Contributor

@mcclurgm mcclurgm commented Mar 11, 2019

I'd like to bring this issue back up, since it seems to be dormant for a while. This behavior is honestly maddening, and it seems pretty much unique to Elementary. I don't know how they did it in GNOME, but they follow the independent behavior as you described.

I would like to expand on this too: it's not just that I save files to Downloads a lot, I often want to use "save as" to copy a file in the same directory. On every other file manager I've used, I can pretty much just rename the file and press enter and it'll go to the original directory. On elementary it goes to the last viewed directory, as you said. But if we change it to just be so that all save dialogs default to the last directory used in any save dialog, that behavior would be broken.

Again, GNOME implements this as I expect. It seems to me that we could just look at the native dialog implementation and copy that behavior, although I know that's easier said than done. I don't really have the skills in Gtk or C to do this myself unfortunately.

@jeremypw

This comment has been minimized.

Copy link
Collaborator

@jeremypw jeremypw commented Mar 12, 2019

A "FileChooserNative" portal is currently being worked, with a view to replacing the existing Gtk module hack. This can be revisited when implementing the new all-elementary chooser.

@zedtux

This comment has been minimized.

Copy link

@zedtux zedtux commented Mar 26, 2020

We are a year after the last comment by @jeremypw, is there any news?

@jeremypw

This comment has been minimized.

Copy link
Collaborator

@jeremypw jeremypw commented Mar 26, 2020

There was going to be a portal sprint in Europe this summer but that is likely to be to be postponed given the current COVID situation.

@zedtux

This comment has been minimized.

Copy link

@zedtux zedtux commented Mar 26, 2020

Thank you for the status update.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.