Closed GoogleCodeExporter closed 9 years ago
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
Original comment by jkirschn...@gmail.com
on 25 Jan 2011 at 11:18
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
Original comment by fmorbini
on 26 Jan 2011 at 12:16
Original comment by fmorbini
on 7 Feb 2011 at 4:00
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.
Original comment by fmorbini
on 7 Feb 2011 at 8:32
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
Original comment by jkirschn...@gmail.com
on 14 Feb 2011 at 8:42
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
Original comment by jkirschn...@gmail.com
on 14 Feb 2011 at 8:54
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.
Original comment by fmorbini
on 14 Feb 2011 at 9:53
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
Original comment by jkirschn...@gmail.com
on 14 Feb 2011 at 11:02
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());}
Original comment by jkirschn...@gmail.com
on 15 Feb 2011 at 5:27
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.
Original comment by fmorbini
on 15 Feb 2011 at 6:19
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/
Original comment by jkirschn...@gmail.com
on 15 Feb 2011 at 7:11
ok, please try the latest committed revision (134). Thanks for the help in
fixing this.
Original comment by fmorbini
on 15 Feb 2011 at 8:18
Yep works fine now, thanks for attending to this feature request.
Original comment by jkirschn...@gmail.com
on 16 Feb 2011 at 11:58
Original issue reported on code.google.com by
jkirschn...@gmail.com
on 23 Jan 2011 at 8:15