http://calvados.di.unipi.it/
https://github.com/STEllAR-GROUP/hpx

Coffman-Graham Algorithm

Links : https://medium.com/@bolerio/scheduling-tasks-and-drawing-graphs-the-coffman-graham-algorithm-3c85eb975ab

What is needed:

Dev Branch:
Building and testing the whole C++ project. (OS: Linux only)

Master Branch:
Buidling C++ ExecutionGraphServer, and GUI-Client for

• Linux
• OsX
• Windows

Stiching together the ExecutionGraphServer into the Electron App (urgh...)

Approaches:

• Make docker containers with all dependecies installed (linux: ubuntu, macOs?, windows??) and use them to build the whole setups. Where can we setup this stuff? Travis? GitLab?

• Write Travis bash scripts -> to build at least for ubuntu and macOs... and AppVeyor for Windows.

Second approach sucks but is the way people to it ...? However with the docker approach we can run the build locally and its not that frustrating. We can also just Setup Travis Bash scripts to run docker and publish the docker containers and use them from Travis...

Everything could be steered with cmake -> Building C++ /Building GUI-Client with npm,
Fixing stuff for the Electron-App, placing the DLL at the right place (OS dependent shit...)

@simonspoerri what do you think?

Tasks towards a GUI using the chromium embedded framework (CEF):

• Try jsPlumb and other Visualization Tool kits to look if it is possible to design draggable nodes and make connectecion to them
• CEF Framework in cmake build integrated which downloads CEF and uses it in the cefsimple test.
• Setup a simple html application which routes commands from java script to C++ and vice versa.
• Logger added (spdlog)
• Superbuild added
• Make some design specifications on how to interface between GUI and the Execution Graph
• Write a fricking awesome CEF application where the GUI Elements and the ExecutionGraph Logic are separated and well structured. Interfacing via
  HTML JavaScript GUI <-> Json <-> C++ Cef GUI <-> Execution Graph
• Flatbuffer Serialization for Communication/Graph Serialization implemented
• Backend Communication Pipeline setup ( Http Request Handlers)
• Testing the angular page with the backend (add/remove nodes/graphs...)

Tasks towards a GUI using the chromium embedded framework (CEF):

• Try jsPlumb and other Visualization Tool kits to look if it is possible to design draggable nodes and make connectecion to them
• CEF Framework in cmake build integrated which downloads CEF and uses it in the cefsimple test.
• Setup a simple html application which routes commands from java script to C++ and vice versa.
• Logger added (spdlog)
• Superbuild added
• Make some design specifications on how to interface between GUI and the Execution Graph
• Write a fricking awesome CEF application where the GUI Elements and the ExecutionGraph Logic are separated and well structured. Interfacing via
  HTML JavaScript GUI <-> Json <-> C++ Cef GUI <-> Execution Graph
• Flatbuffer Serialization for Communication/Graph Serialization implemented
• Backend Communication Pipeline setup ( Http Request Handlers)
• Os X Application startsup/quits perfectly, no memory leaks...
• Designing the first shot of the Angular application
• Testing the angular page with the backend (add/remove nodes/graphs...)
• Finalizing the angular application ...

• Backend (master) saves and loads the graph to the m_rootPath of the filesystem (given at startup)
• open,save-Component calls the service to save/load the graph and delivers in the case of save the serialized visualization flatbuffer (backend has no knowledge about this buffer). Backend serializes the graph and the visualization buffer into file schema ExecutionGraph.fbs
• [ ] Client: Save Implement the Visualization serialization
  • What should we serialize (Pos. of nodes. etc...)
• [ ] Client: Load Implement how and where we setup all visualization properties (model.Node.uiProps, model.Connection.uiProps model.Graph.uiProps?. Maybe an effect: UpdateVisProps... for the corresponding models data structures...? So after LoadGraph we dispatch the UpdateVisProps ??

Implement some easy first-use of graph -ayouting algos.
Maybe implement the execution order (easy) in the client as well to use the priorization as a layer-layout mode.

• Moreau-Timestepper and Mass-Spring implemented in TS (works, but not optimal -> improve spring, and other settings...)
• Improve...

Currently after GraphManipulationServiceBinaryHttp::addNode we have not setup the socket type strings.
They reside in the GraphTypeDescription. It is currently only needed for the type-tooltip-tool to show the types.
Maybe we directly lookup the correct type inside the tool (making the tool accessible to the current GraphTypeDescription). So we dont need to save the type string in the model.Socket..?

Or if we want to store the types inside the Socket -> where should we setup these, after AddNode where we init all uiProps as well?...

This is a relatively easy task.
The Sockets should definitely use a RawAllocator (foonathan) such that the memory is continuous for each type.
This is easily implemented and added.

• Node::CTOR : takes the SocketFactory templated over the TConfig
• The SocketFactory uses a internally a RawAllocator (templated) which is used for the allocation of the Socket.

Make an option (in the connection style tab of drawer) such that nodes are adjusted
to the width the inside text spans. (css?)

Is this fixable? Maybe :)

• Fix alignement
• Maybe add an offset for the arrow...