5 ms·

> If you need a gui, you are automatically in domain-specific territory. The author specifically describes a platform in which domain specific concerns are fac

by weberc2 10y ago

> 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.

dahart 10y ago
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.
lgas 10y ago
Yes, it seems like something like Naked Objects[0] combined with domain-specific plugins / components could do quite nicely. 0: https://en.wikipedia.org/wiki/Naked_objects https://en.wikipedia.org/wiki/Naked_objects

by weberc2 10y ago

dahart 10y ago

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.

lgas 10y ago

Yes, it seems like something like Naked Objects[0] combined with domain-specific plugins / components could do quite nicely. 0: https://en.wikipedia.org/wiki/Naked_objects https://en.wikipedia.org/wiki/Naked_objects