# HierarchyDecorator for Unity: Installation and Editor Setup

> HierarchyDecorator is an MIT-licensed Unity Editor plugin that adds headers, styles, icons, layer controls, breadcrumbs, and active-state controls to the Hierarchy window. It targets Unity 2018.4 and later, but its settings storage and several planned features introduce project-specific trade-offs.

**WooshiiDev/HierarchyDecorator** — Lightweight Unity Plugin transforming the Hierarchy into what it should be. Adds headers, styles, icons and more.

- Repository: https://github.com/WooshiiDev/HierarchyDecorator
- Stars: 1,383 · Forks: 81
- Language: C#
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/wooshiidev-hierarchydecorator

## What HierarchyDecorator Changes in Unity

HierarchyDecorator addresses a specific Unity Editor problem: the default Hierarchy is largely a plain list of GameObjects, so important distinctions such as headers, component identity, layer assignments, and active state may not be obvious at a glance. The plugin extends that window for developers who work with large or deeply nested scene structures. Its intended audience is Unity users who need to scan and edit scene organization without treating the default Hierarchy as their only source of context.

The available features go beyond color. Headers and styles can divide the scene into readable regions. Component icons add information beside objects, while breadcrumb lines visually connect selected rows to their positions in the hierarchy. Layer labels can be exposed in the Hierarchy, and clicking a displayed layer can open a selection control for changing it. Active-state toggles allow users to see and change an instance's active state directly in the Hierarchy.

The plugin does not change the scene architecture described in the repository. It is an Editor extension intended to improve how existing Unity objects and component information are presented. That distinction matters for projects evaluating it as a developer tool rather than a runtime system. Nothing in the supplied documentation describes changes to player builds, gameplay code, or serialized scene data beyond the explicit layer and active-state controls.

## How Settings Drive the Hierarchy Extension

HierarchyDecorator uses a ScriptableObject as its settings container. According to the README, one is required for the plugin to run. If the object is deleted, the plugin creates another under `Assets/HierarchyDecorator/`. The same settings are accessible through Unity's Preferences area. This creates a project asset rather than a purely transient editor preference, which makes the configuration visible and shareable through the project, but it also means the generated asset and its changing schema need to be considered during upgrades.

The settings are organized into functional areas. General toggles control whether active-state indicators appear, whether they use a checkbox or dot, and whether click-and-drag swiping can change multiple instances. Additional controls limit swiping to the same initial state or to the current selection, while Depth Mode determines which instances qualify. Breadcrumb settings control visibility, line color, solid, dash, or dotted styles, and horizontal display. Background settings can alternate two colors between Hierarchy rows.

This is a centralized configuration model rather than decoration attached independently to every scene. It gives one place to disable or modify the features, but the README also warns that the settings design may change as development continues. Projects should therefore avoid external tools that assume the internal field layout will remain stable unless the repository documents such compatibility.

## Installing HierarchyDecorator Through UPM or Git

The README provides a downloadable Unity Package, a repository ZIP, a git URL, and OpenUPM as installation routes. For a command-line-oriented installation, the documented OpenUPM command is:

```bash
openupm add com.wooshii.hierarchydecorator
```

That command registers the package name `com.wooshii.hierarchydecorator`, matching the repository's `package.json`. Readers using OpenUPM should expect the package manager to resolve that package rather than an invented local path or alternate package identifier.

Unity projects can also add the repository directly to `manifest.json`:

```json
"com.wooshii.hierarchydecorator" : "https://github.com/WooshiiDev/HierarchyDecorator.git"
```

The supplied manifest entry is a fragment rather than a complete JSON document. It belongs in the dependency list used by the target Unity project, and the surrounding commas and braces must follow that project's existing manifest structure.

After installation, open the plugin's settings through Unity Preferences. The README does not provide an exact menu path, so no more specific navigation claim is justified. If the required ScriptableObject is missing, the documentation says to expect one under `Assets/HierarchyDecorator/`. A first useful check is to enable a small subset of the General controls, such as active-state toggles, and confirm that the indicators appear in the Hierarchy. This creates a concrete first use without changing many objects at once.

## Active Toggles, Layer Editing, and Breadcrumb Scope

The clearest interactive feature is the active-state toggle. Its display can be configured as a checkbox or a dot, and the Hierarchy can expose whether an instance is active. Swiping is intended to reduce repeated clicks across rows, but its scope depends on settings. `Swipe Same State` limits changes to instances matching the first selected state. `Swipe Selection Only` restricts the operation when a selection exists, while `Depth Mode` governs which instances are accepted during a drag.

That flexibility comes with a need for careful configuration. A broad swipe operation can change many active states at once, particularly when selection and depth restrictions do not narrow the operation. The README does not add an undo warning or document a confirmation prompt, so the practical safeguard is to enable the narrowest restrictions suitable for the scene before testing swiping.

Layer behavior is similarly concrete. `Show Layers` exposes the assigned layer, and `Click To Select Layer` turns the label into a control for changing it. `Apply Child Layers` controls whether an update is propagated to child GameObjects. This last setting is the most consequential distinction because changing a parent layer and changing an entire subtree are different editing operations.

Breadcrumbs are visual rather than structural. Their settings draw trails between Hierarchy objects to make tree positions easier to follow. Solid, dash, and dotted styles are available, with configurable color and horizontal lines. Instance settings affect breadcrumbs drawn for an instance and its siblings, while Hierarchy settings affect greater depths. That division supports local inspection and broader structure, but it can also make visual density harder to manage when too many levels and styles are enabled.

## Current Features Versus Planned Hierarchy Changes

The README distinguishes current functionality from planned work. Current items include hierarchy headers and styles, tag and layer selectors, breadcrumbs, and component icons. Planned items include GameObject icons, folders, script error and warning popups, editor flag selectors, and team or individual settings modes.

This distinction prevents the feature table from being read as a full release contract. A project that expects virtual folders in the Hierarchy, for example, should not select this plugin on that basis because the README marks folders as planned. The same applies to inline script diagnostics and GameObject icon customization. The supplied settings excerpt also ends during the Styles description, so it does not establish the behavior of every visual option or any future schema.

The README's comparison table says other hierarchy extensions offer some planned capabilities. It does not identify those products or describe their implementation, so they cannot serve as a technical comparison. The useful project-specific question is narrower: does a team need only the current presentation and selection controls, or does its workflow depend on one of the explicitly planned features? Only the former is supported by the documented current set.

## Maintenance, Versions, and Upgrade Considerations

The repository is not archived, and its last push was on 2026-07-18. That is recent activity, but recency alone does not establish compatibility with every Unity project. The listed releases include `v0.12.0` on 2026-02-15 and `v0.11.2` on 2026-02-14, after `v0.11.1` on 2025-11-29. The repository's `package.json` reports version `0.12.1`, while the latest release listed for the article is `v0.12.0`. That difference should be resolved before a team assumes the default branch and newest release are equivalent.

The declared minimum is Unity 2018.4, and the package has no dependencies. The absence of declared dependencies simplifies package resolution, but the documentation does not provide a tested Unity Editor version range beyond that minimum. It also does not document migration steps for the ScriptableObject settings asset. Since the settings design may change, upgrade testing should include opening the existing asset and checking the plugin's main controls after updating.

The MIT license permits reuse and modification under its conditions, including preservation of the applicable copyright and permission notice. Teams should review the repository's `LICENSE.md` for their intended distribution model. License identification does not answer whether a generated settings asset should be committed, ignored, or customized for each developer, so repository-specific source control policy remains necessary.

## HierarchyDecorator Compared with Unity's Native Hierarchy

Unity's native Hierarchy is the real alternative for teams that do not want an additional Editor extension. The native approach leaves the standard Unity window in place and relies on its existing object list, selection behavior, inspector, and project organization conventions. It does not provide the documented HierarchyDecorator headers, component icons, breadcrumb styles, or layer controls through this plugin's configuration surface.

HierarchyDecorator takes the opposite approach. It inserts an Editor layer that reads project settings and augments Hierarchy rows. Its advantage is direct scene visibility and interaction, particularly for users who need to see layer values or active state in the tree. Its cost is the added dependency and the ScriptableObject generated inside the project. A team that values a plain Unity interface with fewer plugin-specific settings may find the native Hierarchy more predictable.

The choice depends on workflow rather than feature count. HierarchyDecorator is more relevant when hierarchy readability is an active editor requirement. It is the wrong choice when the desired workflow depends on folders or script warning popups that the README lists only as planned, or when maintaining a project-level settings asset is unacceptable.

## Conclusion

HierarchyDecorator is a reasonable choice for Unity teams that want a configurable Hierarchy window and can accept a project-level settings asset. It is less suitable for projects that need folders, GameObject icons, script warning popups, or a documented shared team settings workflow, because the README lists those as planned rather than current features. Teams should first verify the Settings asset format, especially whether its design and stored Editor preferences remain compatible across their Unity versions. Then confirm that automatic layer changes, swiping, and generated assets match their project conventions before adopting the plugin broadly. The final adoption decision should follow inspection of the settings asset generated under `Assets/HierarchyDecorator/`.

## FAQ

### What Unity versions does HierarchyDecorator support?

The README and `package.json` identify Unity 2018.4 as the minimum supported version. The documentation does not provide a broader tested Editor version range.

### How do I install HierarchyDecorator in a Unity project?

The README lists a Unity Package download, a ZIP, a git URL, and OpenUPM. The documented package command is `openupm add com.wooshii.hierarchydecorator`, while a git-based Unity installation can use the repository URL in `manifest.json`.

### Where are HierarchyDecorator settings stored?

HierarchyDecorator requires a ScriptableObject settings object and exposes it through Preferences. The README says that if the object is deleted, another is created under `Assets/HierarchyDecorator/`.

### Can HierarchyDecorator change the layers of child GameObjects?

Yes. The `Apply Child Layers` setting controls whether changing a layer is propagated to child GameObjects. The README does not document a confirmation or undo policy for that operation.

### Does HierarchyDecorator include folders and script warning popups?

Not according to the README. Folders and script error or warning popups are listed under planned features, so they should not be treated as current functionality.

## Sources

- [Issues](https://github.com/WooshiiDev/HierarchyDecorator/issues)
- [License: MIT](https://github.com/WooshiiDev/HierarchyDecorator/blob/master/LICENSE)
- [README](https://github.com/WooshiiDev/HierarchyDecorator/blob/master/README.md)
- [Releases](https://github.com/WooshiiDev/HierarchyDecorator/releases)
- [WooshiiDev/HierarchyDecorator on GitHub](https://github.com/WooshiiDev/HierarchyDecorator)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wooshiidev-hierarchydecorator