After several coding jams the Log service is starting to have sparkles.  I wanted to make it "better" than eclipse's console to quickly see status and diagnose issues.  Having a good logging system is the cornerstone of workyness :)

I want to make the webgui Log service more capable and easier to use than eclipses ...
It's a work in progress at the moment, but some nice features will include, directional sorting, logging selection, client filtering, class filtering, thread filtering, and any more bells and whistles I can think of.
Good Logging is the cornerstone of Worky ... heh at the moment though I have not solved the log level = debug go supernova problem ... but I'm pretty confident I'll figure it out 

2019.10.28 - Arduino webgui oscope "mostly" worky again ...  besides being completely borked with the (pin is a string) change - it never has done screen blitting rolling of traces.  Which I'll try to do.

Now anywhere error(), warn() or info() are used - status appears, is counted and can be dismissed.

There have been many bug fixes to the webgui ui.  Examples and new files are now "downloadable" to your local file system.

Polly now has a simple working ui - with "set keys" which sends the keys to the security service

2019.10.19 - Easier to understand security

2019.10.13  New Command and Status boxes - you can use the MRL Cli to quickly send commands and see results even without the Python service.

call any function /{name}/{method}/{p0}/{p1}...  
some additional "helper" methods pwd ls cd

tooltips now on some of the input fields

2019.10.05  New "Virtualize" button in service menu

A new virtualize button exists in the service menu.  For me its very handy to be able to switch certain services into "virtual" mode.   When you click on Runtime it sets all services and all new services created thereafter to virtual mode.  Other services can be set individually.  Runtime is like a big switch.

I broke and manage to repair the list methods and show json functions.  Both of which can be very helpful looking at the current state or viewing the capabilities of a service.

Likely, I'll be moving on to Arduino next ... I noticed it was pretty bork'd up ...

Hello,
I wanted to show what direction I'm heading in with my latest updates.  There is considerable amount of changes under the hood that affect the framework of MRL.  
In Summary :

• Any MRL can potentially be connected to another instance of mrl without additional services
• Multiple MRLs can all be connected together in a large complex network, and messages from one will get routed to correctly to the other (ie routing is working)
• TimeEncoders are a real thing - they work like physical encoders, but use time estimations to guess where positions are.

There are some UI updates too.  The webgui now behaves similarly to the swing gui, in that there are no more "little frustrating boxes".  Instead its much more similar to the SwingGui.  You can quickly search for your service, and when the tab is selected - the service specific UI appears (like the SwingGui)

The InMoov composite services will have easy to use sliders for positioning, and they can toggle between control mode and read mode - allowing quick positioning and checking of angles

I'm busy trying to get all the parts in to make a pleasurable switch from the SwingGui to the WebGui.  The major integration test will be how well I can create gestures and run simulations on virtual inmoov.  During this time it would be helpful to try to understand how configuration is currently done and what would be the optimal configuration routine(s)

I think some of the current ini files were generated by a web app @ inmoov.fr -  I'd like the same concept, but the local instance should be capable of running through a calabration routine and generating the resultant configuration in the form of a configuration.py script.

 - Cheers