39Wc

Why not release the source code as an open source project then, and add a proper maven dependency instead of bundling a jar file?

Seems the entire game engine is missing from the source code, instead it comes bundled with a jar file in the classpath called "mead.jar".

I wonder why the author thought that was a good idea. I was actually looking forward to studying the game engine itself.

Trade Republic, once the go to app for the European FIRE community, launched a UI update and the users are less than happy. See the latest reviews on the Google Play Store.

This will probably become a case study in some executive MBA program. How to let UX designers ruin your company.

Deceptive writing. It's just the outdated (and presumably insecure) Hive Nano 1, that is being deactivated early, and for a good reason probably. The author should explain the necessity to switch off insecure products and motivate people to stay up to date in terms of IT security. Instead, the text makes it sound like some villain corporation is trying to screw their customers for no good reason at all.

https://community.hivehome.com/s/article/Nano1-shutdown-Step...

Apache Causeway [1] generates a RESTful API that is HATEOAS compliant, and exists in parallel to the built-in viewer that is based on Wicket.

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

Also worth mentioning, the Sprotty project by Mirko.

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!

Thanks for taking the time to reply to my comment and sorry for the short reply from my side - I am in a hurry.

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.

Great! I am a fan of seeing diagrams being generated instead of manually drawn.

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)?