21 karma · joined December 31, 2019
I wonder why the author thought that was a good idea. I was actually looking forward to studying the game engine itself.
https://community.hivehome.com/s/article/Nano1-shutdown-Step...
There are a few HATEOAS client projects out there, such as [2], that will generate a UI from such a (Restful) API. As far as I know it works quite well, but of course it's a bit rough on the edges.
One interesting observation is that the Wicket UI generated by Causeway does not itself use the RESTful API, but it uses the same meta model that is also used to generate the API.
[1] https://github.com/apache/causeway [2] https://github.com/lagoshny/ngx-hateoas-client
https://github.com/eclipse/sprotty
This integrates with XText, ELK and the VS Code LSP and allows you to generate diagrams for your own DSL!
In case you were looking for a similar text-based integration of a layout engine with your tool there is a textual DSL for ELK called ELKT:
http://rtsys.informatik.uni-kiel.de/elklive/
One could certainly feed that into a binary running the kernel similarly to how a DOT file is fed into graphviz.
I was a bit disappointed however to find out the project uses Graphviz/DOT under the hood.
What would be the reason not to try a newer rendering engine such as as the Eclipse Layout Kernel (ELK)?