search

tryashtar / nbt-studio

An up-to-date NBT viewer and editor with lots of new features
500 stars 40 forks source link

Feature Request : Automatic Sort? #12

Open barraIhsan opened 3 years ago

barraIhsan commented 3 years ago

NBT Studio seems to not sort a to z automatically It kinda annoying when you open for example like the level.dat image So, when you want to sort, you have to click the object and click the sort button image So please, maybe there is a setting that automatically sorts those, just like NBT Editor

tryashtar commented 3 years ago

Well, I tried implementing this, but it's a bit wonky. Let me know what you think: NbtStudio.zip

Mostly the challenges are how often to sort. I can make it sort every time you make a change, so all your new tags end up with their neighbors, and stuff like drag and drop would just ignore the position you selected for compounds. That might be potentially slow though, especially with bulk changes, since I currently don't really have a way to suppress multiple updates coming from the same source (it's something for me to look into later...)

The version I posted above just sorts whenever you open a file. Specifically, it sorts everything you have open at the top level, so if you import, it will re-sort already imported files, and it will miss stuff if you open a folder. Also it tends to mark every file you open as unsaved. If just sorting on read is what you want, I can probably make this process a little less hacky.

barraIhsan commented 3 years ago

Well, I tried implementing this, but it's a bit wonky. Let me know what you think: NbtStudio.zip

It still do the same image Also, why does the NBTEditor does this fine?

tryashtar commented 3 years ago

You have to click on the sort button to set which autosort you prefer. Sorry, I forgot to mention that. NBTExplorer simply sorts the tags of the compound as it reads them from disk, which I'm not a fan of because I like to view and preserve the true order of tags. So at the very least, this feature requires more consideration from me because I want it to be configurable. Also, testing in NBTExplorer just now, it looks like it has an issue where renaming a tag doesn't update its position until you add another tag beside it. That's the kind of thing I definitely want to avoid.

barraIhsan commented 3 years ago

Oh it work! Also it seems that when you open a file, it marked as * (not saved) image (opening the level.dat_old cause the leve.dat already sorted)

tryashtar commented 3 years ago

Yeah, I'll fix that later when I finish this feature. I'm curious, which of these two would you prefer?

barraIhsan commented 3 years ago
  • Compounds are always sorted. Adding new tags or renaming them puts them in order

This Oh also, when you restart the program, the settings are not stored. Is it not yet implemented (so the data is temporary)?

tryashtar commented 3 years ago

Alright good to know. About the settings, I thought I had that working, but I may have missed it. Anyway, it's going to take some time before I finish this feature. Today's test was a good experiment to find out what work is required and where the pain points are. I do agree it's an important feature so I'll try my best

barraIhsan commented 3 years ago

Ok, thanks!

annenveritas commented 3 years ago
  • Compounds are always sorted. Adding new tags or renaming them puts them in order
  • Files are sorted when loaded, but changes made after that can result in out-of-order tags

I would vote against automatic sorting since it would make it harder to use the Studio for editing arbitrary NBT data: sometimes one wants their data just the order they've added it. A checkbox (or other toggleable setting) for automatic sorting would be nice though.

And by the way, there seems to be an issue with sorting of compounds that have nested compounds: their contents also get sorted, and that is irreversible - undoing restores just the immediate children's order, but the nested compounds' children stay sorted. The way I would prefer this, is sorting affecting just the immediate children of a compound chosen; though I understand that many users would probably prefer a deeper sorting so that they wouldn't have to sort manually all of the nested compounds (in case they want everything sorted), - so maybe a nice thing would be to give users a choice on how they want their sorting.

tryashtar commented 3 years ago

I would vote against automatic sorting since it would make it harder to use the Studio for editing arbitrary NBT data: sometimes one wants their data just the order they've added it. A checkbox (or other toggleable setting) for automatic sorting would be nice though.

I agree 100%, I've already modified the NBT library to allow compound tags to have a consistent custom order because I think it's very important. Auto-sort will definitely be a default-off option.

The issues with undo are what's causing this to take so long. If auto-sort counts as an undoable action (which it does currently because the codebase basically forces every action to be undoable), then every real action you take gums up the undo history, and undoing un-sorts. Which means either it's constantly unsorting and resorting, or you just can't undo ever, since it should re-sort right away. If auto-sort doesn't count as an undoable action, the program crashes when you try to undo because tags that used to be in one place are now somewhere else.

I really need a C# tutor to help me with my design...

annenveritas commented 3 years ago

The issues with undo are what's causing this to take so long. If auto-sort counts as an undoable action (which it does currently because the codebase basically forces every action to be undoable), then every real action you take gums up the undo history, and undoing un-sorts. Which means either it's constantly unsorting and resorting, or you just can't undo ever, since it should re-sort right away. If auto-sort doesn't count as an undoable action, the program crashes when you try to undo because tags that used to be in one place are now somewhere else.

Hm, well, as a temporary workaround, maybe you could make the auto-sort actions somehow group with the last manual action, so that undoing once would first undo all of the auto-sorts (maybe with a temporarily internally disabled auto-sorting) and then it would undo that manual action, that followed by auto-sort again, but now grouped with the action that was initially further in the undo history. This way, also, redoing would be just repeating the manual action followed by an auto-sort.

Or maybe it could've been faster and easier just copying the state of the sorted compound just before the post-action auto-sort (which in this scenario wouldn't count as undoable), and restoring that state in case of an undo (thus avoiding all of the unsorting, though at the cost of some more RAM).

tryashtar commented 3 years ago

Combining it with the previous action isn't a bad idea, but at the moment I'm not sure whether the infrastructure allows for that. I also want to change my current bad event-driven NBT tags and nodes that run absurd amounts of code when anything changes to a kind of "mark dirty and synchronize later" approach. That will, I think, make autosort much easier to handle. But I'm really struggling with it.

tryashtar commented 3 years ago

Just a random update, I've been working on this rewrite continually since the end of July (and a bit earlier). It's been very slow and honestly quite stressful for me. The code didn't compile at all for around a month. Just last week, I fixed all the compiler errors and my pace improved, as I was able to test things. You may be disappointed to hear that so far, I am still working merely on restoring functionality I tore out in the process; I haven't even started working on auto-sort as a feature. I decided to push the mark-dirty branch so anyone curious could see how my work was coming along.

The features I still need to restore include:

I am rather pleased with the state of the program infrastructure after the rewrite, though it took a lot of headaches to get it here, since I'm so amateurish. I appreciate your patience in the meantime; I hope that once I've finished restoring the existing feature set, implementing this and the remaining feature requests will be swift and elegant.