Tree View GUI #4
Assignees
Labels
enhancement
New feature or request
Comments
Offroaders123
added a commit
that referenced
this issue
Aug 1, 2023
Demoing out how I want to display NBT data using a tree view, like how NBTExplorer and other apps commonly show NBT to users for editing. #4
Offroaders123
added a commit
that referenced
this issue
Dec 8, 2023
TypedArray-like tag entries are now rendered correctly in the Tree View! The issue is that my current implementation for the tree view component sections isn't specific enough to each tag type, and the types for each tag's value was being lost because I was iterating over them as plain primitive values, rather than ones of a specific TypedArray type. Ideally I shouldn't be creating new objects just to handle this type information, and the renderer should instead know how to handle it's children properly. This is a temporary fix, I will implement a separate render function for each tag type instead, which will remove the need for making new primitive wrappers just to render the TypedArray values. I also removed the key number counts for compound tags, moved the NBTTree component modules to the main app source folder, and adjusted some control flow for the drag and drop implementation. I plan on hopefully bringing multiple-editor support like STE has, so you can edit more than one file at once. I think I need to add that before any other feature, as those will rely on the base implementation of how the editor works, and right now it only supports one. So it would be one more migration that I can avoid if I can add multi-editor support beforehand. #4
Offroaders123
added a commit
that referenced
this issue
Feb 4, 2024
I don't plan to show them both at the same time, because of performance for rebuilding the whole Tree View each time, but we'll see. Maybe SolidJS is nice at handling that? Not completely sure. Maybe that's where the VDOM may actually help out a bunch, since it would only change parts that it needs to. How can I move the NBTify object-based structure for NBT representation, over to using something more UI-based? Looping over all of the keys and values each time doesn't seem the most reactive. I think it should be more declarative, but I'm not sure how to do that yet. This is at least for demoing how often the tree should be rebuilt, I was probably going to do it when `getShowTreeView()` changes, then rebuild it only when changing view states. It does seem really cool to have a live tree view for real-time SNBT editing too though, so we'll see. Would be great to have! STE can do it with rebuilding your whole site from the editor each time, maybe this isn't *that* performance-heavy. There are still probably some optimizations that can tighten things up here and there though, which likely make all the difference. That's usually how things go, the smallest changes make the biggest improvements. #4
|
Coming back to this now, technically it could be closed because right now it can properly render out the context as a GUI, but it isn't editable from there yet, which is the ideal goal to have. It should not only be editable with SNBT. I started conceptualizing how I might be able to represent an NBT tree with Web Components, and that might work very well in combination with implementing a lower-level setup for the tree view. Using plain SolidJS does work well, I think it might be great to be able to use plain component syntax and HTML to render it too. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
No description provided.
The text was updated successfully, but these errors were encountered: