Add command line option to save a graph into a different representaion about scxmlgui HOT 13 CLOSED

I had a look at the code and found a possible route for this extension.
The problem is that all the file loaders have dependencies on JDialogs for 
asking and confirming values. This is not a good route for a command line 
version, as dialogs would pop up, if you want to automate things.

My proposal would be to a) simplify the import/export handlers to take all 
parameters from for example a map and not ask again and b) signal the results 
via response codes and or complex return objects.

Once this is done, it's quite easy to call the loader from the command line. 
One more obstacle I found was the it seems that the graph objects themselves 
(mainly the class mxGraphComponent) would create some UI object which is not 
disposed, that's why I needed to force shut the app via System.exit, might be 
related to my misunderstanding of the code.

In the following there is another method in the IMGImportExport class which 
does not ask for transparency, so that there will be no UI dialog.

Maybe you can work with that?

Something like this

        SCXMLImportExport scxmlImportExport = new SCXMLImportExport();
        SCXMLGraph graph = new SCXMLGraph();
        String from = "input.scxml";
        scxmlImportExport.readInGraph(graph, from, false);
        IMGImportExport fie = new IMGImportExport();
        mxGraphComponent m = new mxGraphComponent(graph);
        fie.write(m, "output.png", false);
        System.exit(0);

Thanks
and good work on the UI so far

Hi, please feel free to send me any patch you may have.
I currently have little time to work on this project so i'll take a while to 
review your suggestions and/or implement them.

One reason the code may not shut down is because of the validation thread: 
com.mxgraph.validation.Validator in the jgraphx library.

Another thing that should be changed to run in text mode is the way in which 
parsing exceptions are displayed. Now dialog boxes are created to show errors, 
in text mode one should just print the errors to screen.

one could add a flag in the main editor class to mark a textonly mode that 
would cause all the necessary changes in the other classes.

keep me posted if you have time to work on this.

thanks

in the latest version there is a simple initial implementation of you suggested.
the options are:
-i input_file
-o output_file
-t optional image type (e.g. png, jpg, etc.). If omitted the type will be 
guessed from the extension of the output_file
-l if present it forces auto layout.

Thanks for this change.

It works just as expected.

I do have one minor request.
The whole setup fails, when run as part of an headless ant script.

java.awt.HeadlessException
   at java.awt.dnd.DragSource.<init>(DragSource.java:246)
   at com.mxgraph.swing.handler.mxGraphHandler.<init>(mxGraphHandler.java:245)
   at com.mxgraph.examples.swing.editor.scxml.SCXMLGraphHandler.<init>(SCXMLGraphHandler.java:23)
   at com.mxgraph.examples.swing.editor.scxml.SCXMLGraphComponent.createGraphHandler(SCXMLGraphComponent.java:178)
   at com.mxgraph.swing.mxGraphComponent.createHandlers(mxGraphComponent.java:790)
   at com.mxgraph.swing.mxGraphComponent.<init>(mxGraphComponent.java:666)
   at com.mxgraph.examples.swing.editor.scxml.SCXMLGraphComponent.<init>(SCXMLGraphComponent.java:46)
   at com.mxgraph.examples.swing.SCXMLGraphEditor.startEditor(SCXMLGraphEditor.java:1357)
   at com.mxgraph.examples.swing.SCXMLGraphEditor.main(SCXMLGraphEditor.java:1401)
   Exception in thread "main" java.lang.NullPointerException
      at com.mxgraph.examples.swing.editor.scxml.SCXMLEditorActions.convertNoGUI(SCXMLEditorActions.java:969)
      at com.mxgraph.examples.swing.SCXMLGraphEditor.main(SCXMLGraphEditor.java:1403)

Not sure if this is something easy to fix, to replicate, start the editor in 
headless mode

-Djava.awt.headless=true

The code actually crashes the JVM.

Here is the error report


Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  sun.awt.windows.ThemeReader.getThemeMargins(JIII)Ljava/awt/Insets;+0
j  
sun.awt.windows.ThemeReader.getThemeMargins(Ljava/lang/String;III)Ljava/awt/Inse
ts;+18
j  
com.sun.java.swing.plaf.windows.XPStyle.getMargin(Ljava/awt/Component;Lcom/sun/j
ava/swing/plaf/windows/TMSchema$Part;Lcom/sun/java/swing/plaf/windows/TMSchema$S
tate;Lcom/sun/java/swing/plaf/windows/TMSchema$Prop;)Ljava/awt/Insets;+19
j  
com.sun.java.swing.plaf.windows.XPStyle.getBorder(Ljava/awt/Component;Lcom/sun/j
ava/swing/plaf/windows/TMSchema$Part;)Ljavax/swing/border/Border;+169
j  
com.sun.java.swing.plaf.windows.WindowsLookAndFeel$XPBorderValue.getXPValue(Ljav
ax/swing/UIDefaults;)Ljava/lang/Object;+11
j  
com.sun.java.swing.plaf.windows.WindowsLookAndFeel$XPValue.createValue(Ljavax/sw
ing/UIDefaults;)Ljava/lang/Object;+10
j  
javax.swing.UIDefaults.getFromHashtable(Ljava/lang/Object;)Ljava/lang/Object;+23
1
j  javax.swing.UIDefaults.get(Ljava/lang/Object;)Ljava/lang/Object;+2
j  javax.swing.MultiUIDefaults.get(Ljava/lang/Object;)Ljava/lang/Object;+39
j  
javax.swing.UIDefaults.getBorder(Ljava/lang/Object;)Ljavax/swing/border/Border;+
2
j  
javax.swing.UIManager.getBorder(Ljava/lang/Object;)Ljavax/swing/border/Border;+4
j  
javax.swing.LookAndFeel.installBorder(Ljavax/swing/JComponent;Ljava/lang/String;
)V+18
j  
javax.swing.plaf.basic.BasicButtonUI.installDefaults(Ljavax/swing/AbstractButton
;)V+183
j  
com.sun.java.swing.plaf.windows.WindowsButtonUI.installDefaults(Ljavax/swing/Abs
tractButton;)V+2
j  javax.swing.plaf.basic.BasicButtonUI.installUI(Ljavax/swing/JComponent;)V+5
j  javax.swing.JComponent.setUI(Ljavax/swing/plaf/ComponentUI;)V+135
j  javax.swing.AbstractButton.setUI(Ljavax/swing/plaf/ButtonUI;)V+2
j  javax.swing.JButton.updateUI()V+8
j  javax.swing.AbstractButton.init(Ljava/lang/String;Ljavax/swing/Icon;)V+19
j  javax.swing.JButton.<init>(Ljava/lang/String;Ljavax/swing/Icon;)V+18
j  javax.swing.JButton.<init>()V+3
j  
javax.swing.plaf.basic.BasicArrowButton.<init>(ILjava/awt/Color;Ljava/awt/Color;
Ljava/awt/Color;Ljava/awt/Color;)V+1
j  
com.sun.java.swing.plaf.windows.WindowsScrollBarUI$WindowsArrowButton.<init>(Lco
m/sun/java/swing/plaf/windows/WindowsScrollBarUI;ILjava/awt/Color;Ljava/awt/Colo
r;Ljava/awt/Color;Ljava/awt/Color;)V+14
j  
com.sun.java.swing.plaf.windows.WindowsScrollBarUI.createIncreaseButton(I)Ljavax
/swing/JButton;+26
j  javax.swing.plaf.basic.BasicScrollBarUI.installComponents()V+35
j  
javax.swing.plaf.basic.BasicScrollBarUI.installUI(Ljavax/swing/JComponent;)V+43
j  javax.swing.JComponent.setUI(Ljavax/swing/plaf/ComponentUI;)V+135
j  javax.swing.JScrollBar.setUI(Ljavax/swing/plaf/ScrollBarUI;)V+2
j  javax.swing.JScrollBar.updateUI()V+8
j  javax.swing.JScrollBar.<init>(IIIII)V+81
j  javax.swing.JScrollBar.<init>(I)V+8
j  javax.swing.JScrollPane$ScrollBar.<init>(Ljavax/swing/JScrollPane;I)V+7
j  javax.swing.JScrollPane.createVerticalScrollBar()Ljavax/swing/JScrollBar;+6
j  javax.swing.JScrollPane.<init>(Ljava/awt/Component;II)V+52
j  javax.swing.JScrollPane.<init>()V+6
j  com.mxgraph.swing.mxGraphComponent.<init>(Lcom/mxgraph/view/mxGraph;)V+1
j  
com.mxgraph.examples.swing.editor.scxml.SCXMLGraphComponent.<init>(Lcom/mxgraph/
view/mxGraph;)V+2
j  
com.mxgraph.examples.swing.SCXMLGraphEditor.startEditor(Z)Lcom/mxgraph/examples/
swing/SCXMLGraphEditor;+30
j  com.mxgraph.examples.swing.SCXMLGraphEditor.main([Ljava/lang/String;)V+9
v  ~StubRoutines::call_stub

what is the relation between comment 6 and 5?
By crash you mean exception? A JVM that stops working not because of an 
exception is not an indication of a code problem but of a JVM bug.
Let me know all details required to reproduce your problem. Thanks.

Hi, thanks for your quick response.

Basically the two failures are related.
I started the fsm-editor from the command line using a newly build jar.
java -jar -Djava.awt.headless=true -i input -o output

What happends is that the jvm dies (crashed) and what I posted in comment 6 is 
parts of the content the can be found in the crashlog.

I scheduled the chart generation as part of the jdoc report generation which 
runs on a build server, thus does not have access to a display - the jvm 
parameter can simulate that.

I supsect it's some UI code, which fails due to no display available

Hope that clarifies it

He,

just an update on what I found in the code.
When I disable the look and feel UI manager I get a NullPointer exception - 
maybe that helps a bit more.

So in SCXMLGraphEditor#startEditor method

I changed the UImanager init to say

if(!noGUI) 
{UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());}

yes you suggestion did help.
setting the look&feel caused the jvm crash (bug in jvm)

then the headless doesn't support setting up stuff for drag&drop. A short term 
patch for you is to comment out the lines from 205 to 245 included in the file
mxGraphHandler.java (jgraphx library) package com.mxgraph.swing.handler.
205: DragGestureListener dragGestureListener = new DragGestureListener()
245: dragSource.createDefaultDragGestureRecognizer(graphComponent
                .getGraphControl(), DnDConstants.ACTION_COPY_OR_MOVE,
                dragGestureListener);

re compile jgraphx and then fsm-editor and that should give you a jar that 
works in headless mode.

Hi,

okay thanks for locating this, seems to work now.
What about including a check for headless mode for this drag and drop handling?
like with the following snippit

if(!GraphicsEnvironment.isHeadless()) {
  // setup drag and drop
}

See here for details 
http://java.sun.com/developer/technicalArticles/J2SE/Desktop/headless/

ok, please try the latest committed revision (134). Thanks for the help in 
fixing this.

Yep works fine now, thanks for attending to this feature request.