mogsie / scxmlgui

Automatically exported from code.google.com/p/scxmlgui
0 stars 0 forks source link

Add command line option to save a graph into a different representaion #21

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
This is a feature request

What steps will reproduce the problem?

Opening a graph and saving the layout into a different representation
works as expected.
It would be nice to include a command line option to do this in an automated 
fashion.
For example
java -jar fsm-editor.jar --layout --input inputfile --representation png 
--output outputfile --overwrite

would create a png rendering of the current scxml graph and save the output 
into the specified output file, overwriting any existing instances.

This way it would be easy to include the latest graphs into javadocs using for 
example a custom ant task.

Original issue reported on code.google.com by jkirschn...@gmail.com on 23 Jan 2011 at 8:15

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago

Original comment by fmorbini on 7 Feb 2011 at 4:00

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
Yep works fine now, thanks for attending to this feature request.

Original comment by jkirschn...@gmail.com on 16 Feb 2011 at 11:58