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 As..." Option / New Files from Scratch / Plain SNBT File Support #6

Open
Offroaders123 opened this issue Nov 28, 2023 · 1 comment
Assignees
Labels
enhancement New feature or request

Comments

@Offroaders123
Copy link
Owner

Add the ability to:

  • Save your current edits to a brand new file, without writing to the original one you opened it from.
  • Write a new file to disk based on your own content, from scratch. Right now you can only edit something after having opened another file.
  • Open plain SNBT text files, and allow you to save them back again just as text (expected), but also with the "Save As..." feature to binary NBT as well, including the options provided by the "Format Options" dialog.
@Offroaders123 Offroaders123 added the enhancement New feature or request label Nov 28, 2023
@Offroaders123 Offroaders123 self-assigned this Nov 28, 2023
Offroaders123 added a commit that referenced this issue Nov 28, 2023
Haven't moved these changes to the main branch or production in a while, I think they're about safe now, so I think I'm ready to move things over.

Not quite a 2.0 release technically, but the numbers are there, and I want to work on making Dovetail have a better app experience, and I think moving onto the next stage is part of what that entails. Hence, things like #6. I think I can also start looking into more features like fancier styling, UX, animations, and things like that. And eventually I want to get SNBT syntax highlighting (and hopefully linting/syntax error validation) down the road as well.

In a few spur branches of the project, I tried integrating with Svelte and React, but I don't think my own skills are ready for that kind of step yet. Nor do I think Dovetail is either. Embedding all of React into the app made the bundle size a bit bigger, and it didn't add anything new that the app can't already do. I want to add a framework in when it drastically helps lesten the load of the app's own weight under it's own implementation. I guess that's where we're at with STE, and I don't really want to touch that craziness as of yet, so maybe I don't want to let Dovetail get to that point either. But I think that could also be inevitable, no matter how you choose to build the app. I guess it depends on how you build the app, not what you build it *with*. If you manage things appropriately, I don't think it necessarily has to get out of hand. You can make a total mess out of any tool someone hands to you, be it a framework or a library. You just have to know the most applicable ways to make use of it! Wow this sounded very fancy lol.
@Offroaders123
Copy link
Owner Author

Oh yeah, keyboard shortcuts!

Offroaders123 added a commit that referenced this issue Dec 9, 2023
Want to get keyboard shortcuts working, I just need to figure out a nice way to manage shortcut handling. My only active implementation for shortcuts is in STE, and it's very spaghettish. This is my first thought on how I can handle things, using an enum and a switch statement to check each state a bit better, and to also more explicitly these at the type level.

I want to use a similar pattern to that of what Electron uses for it's accelerator pattern, I just haven't known how to approach managing that quite yet. Trying an enum and Set for this actually seems to be a good idea maybe! Now I just need to set up my own platform-unique handling for things like differing between Win-Linux, and Mac-like.

https://www.electronjs.org/docs/latest/api/accelerator

#6
Offroaders123 added a commit that referenced this issue Feb 4, 2024
Now there is a default `NBTData` object that is used when a file hasn't been loaded yet. I think this goes in favor of better allowing files to be made arbitrarily as well, since this paves the way for allowing new files to be made from the beginning of opening the app.

#6
Offroaders123 added a commit that referenced this issue Feb 4, 2024
This was actually not too bad to implement, heck yeah! Now that everything is modular and more-explicitly defined in it's own groups, it's easier to tell where something should be implemented, and it works across the whole rest of the app as well. Next I'd like to derive the `<input type="file">` picker from the Web App Manifest's file types as well, then it's also only defined from a single place too.

#6
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant