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

open file dialog: start in last used directory across sessions #805

Closed
a773music opened this issue Apr 5, 2013 · 5 comments
Closed

open file dialog: start in last used directory across sessions #805

a773music opened this issue Apr 5, 2013 · 5 comments

Comments

@a773music
Copy link
Contributor

It would be nice if scide remembered (across sessions) where you opened a file last time. It does remember it during a session atm, but on every new session it starts in my user directory, and I have to click through my folders to open a file.

@sensestage
Copy link
Contributor

Hiho,

actually, it would be useful if in this case scide respected the
runtime directory of the interpreter, as set in the preferences.

sincerely,
Marije

On Fri, 05 Apr 2013 08:31:14 -0700
attejensen notifications@github.com wrote:

It would be nice if scide remembered (across sessions) where you
opened a file last time. It does remember it during a session atm,
but on every new session it starts in my user directory, and I have
to click through my folders to open a file.


Reply to this email directly or view it on GitHub:
#805

@jleben
Copy link
Member

jleben commented Apr 8, 2013

Currently the dialog shows the directory containing the currently focused document, if any, or else the working directory of the IDE (which is user home dir if the IDE is started by usual desktop means).

A possible enhancement would be, if there's no current document associated with a file, use the last open location. There's 2 options here:

  1. Use the location of the last focused document associated with a file
  2. Use the "recently opened documents" list, which presists across sessions.

We could even combine this: first cycle through actually open docs in their focus order, if there's none with an associated file, then look up the recently opened documents list.

I think this is better than the working dir of interpreter. On the other hand, we could use the working dir on the condition that it is explicitly overridden via preferences. Even in that case it might be better to only use it if the step (1) above fails, or only if both (1) and (2) fail.

Opinions?

@a773music
Copy link
Contributor Author

I'd prefer something simple, thus I vote for recent files...

@jleben
Copy link
Member

jleben commented Apr 9, 2013

Another improvement would also be to not recreate the dialog each time, but keep one instance hidden after it's first created, then only redisplay it next time. Thus, if the currently focused document is not associated with a file, the last open location in the current sessions would remain unchanged.

This would also mean that the last directory shown in the dialog would persist even if the dialog was previously cancelled.

Of course, this does not address the persistence across sessions, but it certainly makes sense to address both ideas at the same time.

@jleben
Copy link
Member

jleben commented Apr 10, 2013

Solution has been implemented.
See commit 465a5a8.

The open file dialog will attempt to show paths in this order:

  • Current document's path
  • Most recently opened document's path (from persistent list across sessions)
  • Interpreter working directory, if explicitly overridden in preferences
  • User home directory

The save file dialog will attempt to show paths in this order:

  • Current document's path
  • Last document save path in current session (sorry, no persistence across sessions here)
  • Interpreter working directory, if explicitly overridden in preferences
  • User home directory

@jleben jleben closed this as completed Apr 10, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants