This is an unsatisfactory approach that means the scripting in Xwidget will never receive the attention it really requires leaving the scripting as the poor relation with regard to developing actual programs. Without the ability to extend widgets ourselves through scripting, more cores need to be written to allow access to new and fresh data sources but these are closed-source and written in C++ and without the main developer being available 100% of the time the existing cores will degrade over time (generally stop working in relation to their changing data sources) and new cores have been proven to be very slow to arrive.
If the xwidget environment is ever going to be considered as a serious contender for real widget development it MUST incorporate one of the main javascript engines that are available that follow ECMA standards as defined by the ECMA body: https://en.wikipedia.org/wiki/ECMAScript
If Tony, the Xwidget designer was to incorporate a modern 3rd party open source engine (there are several available that others incorporate into their engines) and simply make the additional xwidget functions available to it (via cores) then it would allow developers to use either xwidget's cores or build their own functionality in javascript. It would open the xwidget engine to the world of javascript that is already extant. Hundreds, if not thousands of javascript programs would then be able to run within xwidget. Potentially, most if not all the code that you create for Xwidget would become available to the web.
Feature Request: incorporate ECMA 1.4 javascript (or later version) into the new Xwidget 2.0 environment and watch Xwidget mature into a real widget programming environment.
http://duktape.org/ Duktape is such an embedded environment usable from C++. It would truly transform Xwidget from a toy to a serious tool.Statistics: Posted by yereverluvinuncleber — March 11th, 2017, 4:42 am
]]>