Welcome to yEd Q&A!
Here you can ask questions and receive answers from other members of the community and yEd developers. And you can tell us your most wanted feature requests.

Categories

Custom graph actions via scripting inside yEd

+2 votes
I tend to use yEd for model analysis thank to powerful visualisation capabilities. I tend to import things from Excel and then manipulate graphs using auto-layouts. Sometimes though it is necessary to manipulate the graph in some way to be able to make sense out of it. At the moment I have to resort to manually editing the graph, which is unwieldy if it is large, or, alternatively, manipulating the Excel spreadsheet before importing, which is not always easy due to lack of graph-awareness.

This could have been easyily solved if I could script a custom action via some sort of scripting language within yEd itself. This could open a whole new possibility for extending the tool by end users and sharing the scripts in these forums!

For example, one day I wanted to create additional edges between nodes according to a particular rule based on node names. Other day I wanted to delete (or at least select) nodes which are further than two steps away from a particular 'central' node. Finally, today I wanted to replace relationships between individual nodes in several groups with relationship between the groups themselves. On the last one, I know there is a workaround involving copying and pasting diagram with collaped groups, but it just reinforces the point of being able to extend the tool with custom actions.
in Feature Requests by (300 points)

1 Answer

0 votes
Looks like Java is the language.
by (390 points)
Right! And the way to use it from within the editor is?..
Until they open a slot for custom modules with an API, I guess that hacking is the only way.
But on the other side, they are a business and can't give everything for free. I just hope that it will come in future.
Oh, I see. Actually, I think giving people a way to try out the API could drive the sales if anything.
We already have a way for people trying out the API - all commercial yWorks products may be evaluated 30 days free-of-charge. ;-)
Thomas, that only works for people who are considering your product, but not for those who just want to use yEd in a more powerful way, but then develop a taste for the product by repeated exposure to the power of the API :) Or you could offer professional services around yEd 'plugins', or even run a marketplace like apple store!
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.

Currently there are no plans for providing a scripting API in yEd.

While yEd is a great tool in itself, it was conceived as and always will be a show case application demonstrating the power of the yFiles diagramming libraries. Thus the current policy is not to provide any features that would make it possible to code against the yFiles API (or a wrapper thereof) in yEd.

Additionally, adding support for scripting would contradict the "The Software may not be used as part of an automated process" clause of section 1 "License Conditions" in the yEd Software License Agreement.

Legal Disclosure | Privacy Policy
...