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

"Reset to Default" do not clears recently opened items' list #1232

Closed
rat-moonshine opened this issue Dec 27, 2023 · 8 comments
Closed

"Reset to Default" do not clears recently opened items' list #1232

rat-moonshine opened this issue Dec 27, 2023 · 8 comments

Comments

@rat-moonshine
Copy link
Collaborator

@piotrzarzycki21 reported in #1230 (comment) that Settings -> General -> Reset to Default do not clears recently opened files/projects list.

While I don't remember if we did that intentionally, but I can't think of an argument on that either, now. Let's clear the list unless we think on any repercussion against this.

@rat-moonshine
Copy link
Collaborator Author

rat-moonshine commented Dec 27, 2023

Do we also wants to reset workspace information during a Reset to Default ? If we do, and if user is currently staying on a non-default workspace, it'll immediately deleted and user will be landed to default one by closing any earlier project(s). I'm not sure if such behavior temporary surprise the user.

@rat-moonshine
Copy link
Collaborator Author

Reset to Default now should clear recently opened files/project list (> Build 1449 (Windows)).

@rat-moonshine rat-moonshine added test ready Feature/bug ready for testing and removed in-progress labels Dec 27, 2023
@piotrzarzycki21
Copy link
Collaborator

Do we also wants to reset workspace information during a Reset to Default ? If we do, and if user is currently staying on a non-default workspace, it'll immediately deleted and user will be landed to default one by closing any earlier project(s). I'm not sure if such behavior temporary surprise the user.

I would leave workspace intact.

@JoelProminic
Copy link
Contributor

I agree that I would prefer to not see workspaces reset here, since it would be a pain to recreate them. We do have other options to remove workspaces if needed, and it is pretty efficient at deleting multiple workspaces.

That said, I'm thinking about what a user would expect from the current text. We may want to add some text clarifying what is and is not included:
image

I'm also thinking about the practical cases where we would want to use this feature:

  • Reset to default options - perhaps after more defaults are added/changed after a Moonshine update
  • Clear the settings if they end up in a bad state because of a bug
  • Clear the workspaces if they get corrupted because of a bug. In this case, we might not be able to clean them up with the Workspace management interface

We could consider giving checkbox options for what to delete, with explanations for each entry. This would give more control, but it would be more complicated to implement and test. If we are interested in this, I'd need a summary of the different files we could clear separately.

@JoelProminic
Copy link
Contributor

Another use case would be to clear other stored data, though this might be beyond the scope of the current issue. For example, here are the different files that I see in thee Application Support directory:

~ % cd /Users/-user-/Library/Application\ Support/com.moonshine-ide.development
com.moonshine-ide.development % du -h -d 2 .
  0B	./#airversion
 48K	./Local Store/settings
392K	./Local Store/#SharedObjects
4.0K	./Local Store/rgloader
4.0K	./Local Store/vagrant
 16K	./Local Store/projects
 10G	./Local Store/java
164K	./Local Store/elements
8.0K	./Local Store/templates
 12K	./Local Store/data
  0B	./Local Store/tmp
348K	./Local Store/gems
4.0K	./Local Store/spawn
784K	./Local Store/dominoUpdateSiteGeneration
456M	./Local Store/boxes
 11G	./Local Store
 11G	.

After a reset, the only changes are in settings, #SharedObjects, and elements

com.moonshine-ide.development % du -h -d 2 .
  0B	./#airversion
 24K	./Local Store/settings
224K	./Local Store/#SharedObjects
4.0K	./Local Store/rgloader
4.0K	./Local Store/vagrant
 16K	./Local Store/projects
 10G	./Local Store/java
  0B	./Local Store/elements
8.0K	./Local Store/templates
 12K	./Local Store/data
  0B	./Local Store/tmp
348K	./Local Store/gems
4.0K	./Local Store/spawn
784K	./Local Store/dominoUpdateSiteGeneration
456M	./Local Store/boxes
 11G	./Local Store
 11G	.

@rat-moonshine
Copy link
Collaborator Author

rat-moonshine commented Dec 29, 2023

As far I can remember this, reset mostly affects its SharedObject files, and the settings\*.xml files which usually stores plugin specific settings. I surprise to see that elements also updated - maybe, somewhere something being changes I don't remember now.

@rat-moonshine
Copy link
Collaborator Author

@piotrzarzycki21 @JoelProminic let's close this if the original requirement is fulfilled.

@JoelProminic
Copy link
Contributor

I had some open questions on this issue: #1232 (comment)

I moved them to #1236.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Moonshine-IDE - Bug Fixing
  
Awaiting triage
Development

No branches or pull requests

3 participants