One huge question to ask is why you need an editor specifically for a tree. Do you want a gui, or a format? If you need a gui, you are automatically in domain-specific territory. If you only need a format, maybe you don't need a tree editor at all.
Excel is a great tool for making trees; just add a column that names your parent. I used Excel to create a prototype of an event driven animation sequencing engine for a Disney game. It was more of a state machine / directed graph than a tree, but the only constraint there is data, not the editor. The prototype was later replaced (after the game using Excel shipped) with a gui based tree editor, but not something that could be called "general purpose".
I've long thought that hierarchical file formats come with some pretty bad downsides, from both sides, usage and implementation. You don't need a hierarchical format as long as you are willing to name all nodes and not allow anonymous nodes. Once you do that, you can have a flat file structure with fields that reference other nodes. Once you do that, XML feels crazy. Easier to implement parsers that don't have to do overblown amounts of dynamic memory allocation, easier for humans to read & follow, easier to share references or allow non-tree structures, etc. etc.
> If you need a gui, you are automatically in domain-specific territory.
The author specifically describes a platform in which domain specific concerns are facilitated by plugins, so I don't see why we are "automatically in domain-specific territory". One could easily envision classes of plugins for drawing nodes and edges (perhaps a canvas DSL), plugins for enforcing the domain's specific rules, etc.
I appreciate the reply, but I humbly suggest that nothing is solved by saying "just use plugins". You can't build a good plugin architecture in the first place without understanding the problem domain & workflow.
This is not a new idea, people have tried it before. If there was a decent solution it would already exist. People have tried to make general purpose graph editors & tree GUIs & layout engines, and there have been a bunch of people that thought they were being smart by architecting it to accept plugins. There's a reason you've never heard of any of them; nothing was general purpose enough to stick around, and applications that didn't try to be "general purpose" have vastly superior UI/UX.
I spent several years building a tree editor (the animation sequencing project I mentioned earlier). I've also used well known tree editors in node-based gui apps for decades. (Check out programs for film & game production like Nuke, Maya & Houdini -- they are tree editors.) Simply put, there are not enough commonalities between applications in different domains to make it worth building a shared "general purpose" editor. The workflows, problems, and schemas are too distinct. The tree isn't even close to the hard part anyway.
Excel is a great tool for making trees; just add a column that names your parent. I used Excel to create a prototype of an event driven animation sequencing engine for a Disney game. It was more of a state machine / directed graph than a tree, but the only constraint there is data, not the editor. The prototype was later replaced (after the game using Excel shipped) with a gui based tree editor, but not something that could be called "general purpose".
I've long thought that hierarchical file formats come with some pretty bad downsides, from both sides, usage and implementation. You don't need a hierarchical format as long as you are willing to name all nodes and not allow anonymous nodes. Once you do that, you can have a flat file structure with fields that reference other nodes. Once you do that, XML feels crazy. Easier to implement parsers that don't have to do overblown amounts of dynamic memory allocation, easier for humans to read & follow, easier to share references or allow non-tree structures, etc. etc.