Hi @igor.lobanov
I completely agree, and argue.
2014 :
quite an old stuff for a fundamental subject !
2018 :
so many requests would be fulfilled with scripting embedded (Jython!).
I guess it wouldn't make trouble to commercial users of the API :
If their product have some real benefit for their users, it is mainly because of the fundamental facilities they offer; Yfiles comes with it's layout algorithms and fancy display, and they would also take advantage of a scripting-users community for graphml with the yFiles-API inside Yed : It seems that this kind of phenomena happens for all API that can partially go "public".
As an example, McNeel's Rhino3D (+ Grasshopper plugin) is a very popular 3D "generative-design system", formerly a commercial 3D CAD application, with Grasshopper being the graphing front-end to the API ( visual API components, drag'n drop in a layout + scripting ).
It's constant growing popularity among architects / designers / engineers comes from the fact that it is completely script-able (C#, VB.Net, IronPython).
Whatever the lingo, the accessible API is hugely attractive even for beginners who benefit of a very fast learning-curve due to a very active community, mostly students, "future professionals".
Users with specific knowledge (e.g. topology, engineering-domains ...) publish commercial and public plugins/custom-componnents around it (many great modern stuff indeed), pushing constantly up the range of interest and usability of the main Rhino3D CAD software to a wider audience of professional users; and generates employment at McNeel's : It does, world-wide !
Another fast growing community is the data-scientists/engineers, going from data and mathematics calculation ecosystems to sets visualization.
Here, open-source graph-publishing tools ( say D3js ) are popular because, aside their quality, they have a direct relation to their native scripting lingo ecosystem (open-soure), and have ports/bindings to other ecosystems holding maths calculation environments : Python, Julia, Lua ...
Certainly these examples do not completely fit to yFiles in respect to their usage/aim.
As the representation of the logic's in any kind of field is certainly the best way to start learning/working on any field, Yed is a great tool, and would even be usable for teaching young audience if it was possible to reduce the display of it's features to basic functionnalities ... If you want, see: [cmaptools](
https://cmap.ihmc.us/cmaptools/) : from pupils to phd-physiologists ...
Whatever, yFiles could take advantage of these audience spreading phenomena by allowing commercial (and public) plugins/scripted-solutions over the API itself.
And it would enrich both it's commercial implementers and Yed's users, users-powered !
I love Yed : fast and finely-grained layout algorithms, it's rich rational framework and fancy rendering capabilities; but it is also quite rigid in the framework it provides : working with external data (which is to be very often the case), the user would better apply some "fanciness" directly at the creation of a graphml file outside of Yed to get all the features he expects, and will loose some features like "inheritance of properties in parental relationship" when batch processed by the Properties-Mapper or the Selection tool, which neither support conditional statements across properties nor properties inheritance : this is where a part of the rigidity stands. The lack of ability to select/group elements over crossed-criteria eliminates fine analysis capacities.
To overcome these, extra_labeling + custom_properties does the trick but gets really cumbersome to use :
- at this point, we need to apply selections onto a label_index rather than a field_name !
- then we have selected one or many label_indices, but the Properties View does not reflect which label_index is currently selected ... it is really error prone.
It is also a nonsense to need to store states inside the graph data itself even before displaying it ! Would it mean that Yed assumes not being able to many kinds of discoveries ... ? States are the results of certain queries, not obvious intrinsic properties of the data itself, or hidden properties that one may investigate. Then if the states should become a part of the data, it is upon a users query, not the reverse ... and when data is collected it is for analysis first, then fancy display is certainly of a huge interest, but where is the fundamental interest : fanciness of the user, or fanciness of the display ...? What is the AIM ?
Scripting can hold all this quite easily ! and a few scripts allow forensics ...
All your fancy and powerful layout algorithms can also be parametrized in scripts, though parameters sets could be saved !
Custom layouts that only require a few procedural treatment over your algorithms would allow so many possibilities : I can read hundred "Feature requests" that could get solved.
And scripts are reusable, can be chained ...
Give the scripting-power to your users : from the examples among many, I postulate that they will give it back to commercial yFiles through Yed !
Maybe at the price of some small modifications/enhancements to the Web community's front-end too : at least the [tags-display](
https://yed.yworks.com/support/qa/tags?start=720) : add a simple alpha sorting ! please !
Some asked for Groovy, I plead for Jython : dir(object) = "fast discovery of any API", even if help(object) is often dumb.
And Jython will let you print this to stdout of your choice with a few lines of code :
from java.lang import System
from java.io import PrintStream
from java.io import FileOutputStream
# set java.lang.System.out to a log file : the OutputStream
logfile = ".\my_log_file.txt"
file_output_stream = FileOutputStream( logfile )
System.setOut( PrintStream( file_output_stream ) )
...
System.out.println( "some interesting stuff in my doc ...")
Ain't this nice and concise ? I've had great satisfaction with Jython inside : Sikulix, NodeBox, Geogebra.
I guess we are not the only one hoping for this !
Best Regards, Stan.
