Structure view in Object Browser #90
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This doesn't actually build a structure tree yet. This is just infrastructure work to support multiple browser trees.
This gives all object names a consistent indentation, which is especially helpful in the structure tree, where previously objects with and without icons appeared right next to each other. Enjoy the programmer art, lol
With special handling inside plDrawInterface to display materials and such under the objects that use the associated icicles.
To avoid crashing on invalid drawable spans.
This makes things easier to debug if these variables are used after the widgets have been deleted (or were never created).
This prevents the UI getting into an inconsistent state because of currentItemChanged signals from the tree that isn't currently visible.
Most of these actually also appear somewhere under the scene objects.
This was much less complex than expected.
This points to the main scene object for the avatar being linked, which we would rather not place primarily under the link animation.
dgelessus
force-pushed
the
structure_tree
branch
from
fe0eea9 to
b5579e2
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adds an alternative "Structure" view to the Object Browser, which organizes objects based on how they reference each other, rather than their types. It tries to figure out parent/child relationships and builds a hierarchical tree from that. I find it very helpful for understanding how objects relate to each other in more complicated PRPs. Example screenshot:
The core logic for building the object hierarchy (
pqGetReferencedKeys) is very manual. This is in part because libHSPlasma has no generic way to iterate over allplKeys in an arbitrary object. But I also wanted to manually tweak the iteration order, e. g. to prefer parent-to-child references over child-to-parent backreferences. If I consider all references equally, the resulting tree can look very confusing (e. g. the Scene Node would be nested somewhere under a random object that was arbitrarily chosen as the root).This PR is not quite finished (I paused working on it a year ago - this is the last state from back then). It works quite well for viewing, but I haven't tested how well it reacts when editing PRPs. Many places in the PrpShop code assume that every age/page/object corresponds 1:1 to an item in the tree view, which breaks down when adding a second tree view with a completely different structure. Thus, this PR includes a bunch of refactoring work to separate more of PrpShop's state from the tree view. That should probably be extracted into its own PR and tested separately first.
Depends on #84 and H-uru/libhsplasma#286 (so CI failures are expected for now).