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

Saving dialog ignores default directory #1603

Closed
1 task done
skyblue002 opened this issue Nov 4, 2019 · 5 comments
Closed
1 task done

Saving dialog ignores default directory #1603

skyblue002 opened this issue Nov 4, 2019 · 5 comments
Labels
🐝 resolved/fixed but not released The bug has been fixed and the new version is not released, So it still opened

Comments

@skyblue002
Copy link

Description

The save dialog ignores the default directory and reverts to ~/Documents. The default directory must be navigated to manually every time a note is saved.

  • Can you reproduce the issue? -- It persists after restarting the app.

Steps to reproduce

  1. Go to Menu > File > Preferences, and under General, select Open a default directory, set the preferred folder.
  2. Create a new note.
  3. Save the note.

Expected behavior:

I would expect the save dialog to show the default directory when attempting to save the note.

Actual behavior:

It reverts to showing the ~/Documents directory. If the user is using any other folder as their default directory, they will have to manually navigate to that folder every single time they try to save a note, otherwise it will end up being saved to ~/Documents.

This persists after restarting MarkText.

Link to an example: [optional]
The preferences were set to ~/Documents/MarkText:
MarkText-Preferences
The save dialog defaults to saving in the ~/Documents folder:
MarkText-Save-dialog

Versions

  • Mark Text: v0.15.1
  • Operating system: Linux
@Jocs
Copy link
Member

Jocs commented Nov 4, 2019

@fxha @skyblue002 I think the default save directory need to be the opened folder? then the default setting folder if no folder is opened.

@Jocs Jocs added the 🦁 need discuss the issue or PR need to discuss label Nov 4, 2019
@skyblue002
Copy link
Author

@Jocs I like that idea. It's smart. It's very helpful for if a user is saving to multiple directories. This way the user will not have to change the directory manually if they open another folder and begin working with the files in it, but it's not the default.

@Jocs Jocs added 🦄 feature request New feature or request and removed 🦁 need discuss the issue or PR need to discuss labels Nov 4, 2019
@Jocs Jocs added this to TO DO in 0.18.0 Nov 4, 2019
@fxha
Copy link
Contributor

fxha commented Nov 4, 2019

think the default save directory need to be the opened folder?

That's already implemented on develop.

then the default setting folder if no folder is opened.

I don't agree with you because the default startup directory is set as root directory, so if it's the first editor window it's already handled but not on second window which isn't a problem because it's only the startup directory.

@Jocs Jocs removed this from TO DO in 0.18.0 Nov 5, 2019
@skyblue002
Copy link
Author

I don't agree with you because the default startup directory is set as root directory, so if it's the first editor window it's already handled but not on second window which isn't a problem because it's only the startup directory.

I'm not sure what you mean by this. But, I'm using tabs, not additional windows, so perhaps this doesn't apply to my case.

Will the feature to default to the specified directory when saving be included in the next release? I wasn't clear on that since it was removed from the TO DO.

@Jocs
Copy link
Member

Jocs commented Nov 5, 2019

Will the feature to default to the specified directory when saving be included in the next release? I wasn't clear on that since it was removed from the TO DO.

This feature is already added, and will release in version #1544, so stay tuned.

@Jocs Jocs added 🐝 resolved/fixed but not released The bug has been fixed and the new version is not released, So it still opened and removed 🦄 feature request New feature or request labels Nov 5, 2019
@Jocs Jocs closed this as completed Nov 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐝 resolved/fixed but not released The bug has been fixed and the new version is not released, So it still opened
Projects
None yet
Development

No branches or pull requests

3 participants