prmr / jetuml Goto Github PK

This will likely be encompassed in the larger re-design of the Diagrams and the Parent-Child relationships of their Nodes that we will be tackling later on, but for now I just want to make sure that the issue is not forgotten.

Steps to reproduce:

1. Create a new sequence diagram with a Call Edge between two ImplicitParameterNodes.
2. Copy/Cut it.
3. Paste it.

The Call Nodes behave erratically and don't seem to be fixed properly to their lifelines. Again, this is something that will likely be addressed in a larger redesign, but I just want to make sure it is addressed.

Relevant: https://github.com/prmr/JetUML/wiki/Parent-Child-Relation

Try to use the Nimbus LAF and set this as the only LAF. Let's keep the laf property for now in case we change our mind, but we'll unhook the menu.
Make the grid grey.

For classes Graph Node, and Edge and their implementers:

• Use generics
• Clean up the code
• Make UML documents
• Move into its own package graph

Current GUI conventions have Title Capitalization for menus and button labels.

Steps to reproduce:

1. Create a save a file call it A.violet
2. Restart the application
3. Create a new diagram
4. File -> Recent Files -> a.violet

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
    at com.horstmann.violet.framework.EditorFrame.open(EditorFrame.java:666)
    at com.horstmann.violet.framework.EditorFrame.access$6(EditorFrame.java:658)
    at com.horstmann.violet.framework.EditorFrame$24.actionPerformed(EditorFrame.java:798)
    at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2018)
    at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2341)
    at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
    at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
    at javax.swing.AbstractButton.doClick(AbstractButton.java:376)
    at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:833)
    at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:877)
    at java.awt.Component.processMouseEvent(Component.java:6516)
    at javax.swing.JComponent.processMouseEvent(JComponent.java:3320)
    at java.awt.Component.processEvent(Component.java:6281)
    at java.awt.Container.processEvent(Container.java:2229)
    at java.awt.Component.dispatchEventImpl(Component.java:4872)
    at java.awt.Container.dispatchEventImpl(Container.java:2287)
    at java.awt.Component.dispatchEvent(Component.java:4698)
    at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4832)
    at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4492)
    at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4422)
    at java.awt.Container.dispatchEventImpl(Container.java:2273)
    at java.awt.Window.dispatchEventImpl(Window.java:2719)
    at java.awt.Component.dispatchEvent(Component.java:4698)
    at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:735)
    at java.awt.EventQueue.access$200(EventQueue.java:103)
    at java.awt.EventQueue$3.run(EventQueue.java:694)
    at java.awt.EventQueue$3.run(EventQueue.java:692)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
    at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:87)
    at java.awt.EventQueue$4.run(EventQueue.java:708)
    at java.awt.EventQueue$4.run(EventQueue.java:706)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
    at java.awt.EventQueue.dispatchEvent(EventQueue.java:705)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
    at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)

This will require extracting a common interface for both, for the services used in GraphPanel.

Some of the code and design complexity (e.g., the FileService class hierarchy) is only there to support applet mode, which we will not be supporting. This code should be removed and the result refactored to simplify.

I will also cleanup the business with the file extensions.

The persistence support in EditorFrame can be improved:

• The behavior is in static methods that could be moved to a specialized and testable class.
• There is some old workaround code for a JDK bug that has been fixed. We might be able to use the more straightforward strategy.

@JoelChev, @EJBQ do you use this feature? This is a discussion about whether to remove it. I've never used it and axing it would greatly simplify the implementation of issue #36, which in turn is the preparation for #21

There were some changes to the Graph framework that rendered the existing files unreadable (e.g., I can't load any data from the files in /testdata. What were these changes and how can we recover from them? I need to be able to make all the test diagram files I have work with the current version.

In the framework, it is possible to bring up a properties editor even for an object that has no properties. For example, an note edge. This should not happen: if the object has no property, the behavior should default to do nothing.

However, don't overfit. Checks for some types of problems (like the use of raw types) should be left in, and we'll improve these as we go. If you have any doubt about what rules should be dropped or changed, post here.

Port the Violet 0.23 icons.

Launching raises the following exception, which does not appear to impede the program:

Exception in thread "main" java.lang.ClassCastException: javax.swing.JInternalFrame cannot be cast to com.horstmann.violet.framework.GraphFrame
    at com.horstmann.violet.framework.EditorFrame.setTitle(EditorFrame.java:750)
    at com.horstmann.violet.framework.EditorFrame.readArgs(EditorFrame.java:651)
    at com.horstmann.violet.UMLEditor.main(UMLEditor.java:52)

Modernize the look and feel of the grabber, so it looks prettier.

In Object Diagrams, select call node and point in an object node or other call node, and a call node (erroneously) gets added as a children. This should not be possible.

With the click of a button the current graph should be copied to the clipboard as in 0.21

Write the tests for this class as a means to setup the testing framework.

We should rename the packages to ca.mcgill.cs.stg.* to avoid clashes with the original Violet code. Let's do this last to avoid merge conflicts.

When drawing a return edge, the arrow does not reach the original activation bar, it just floats in the air.

Steps to reproduce:

1. Use the lasso to select an Object Node with a Field Node inside it.
2. Try to move the selection around. The Field Node becomes temporarily "unhooked" from the Object Node and wiggles around in space while you move. It snaps back into place on release of the mouse.

This issue is caused by the translation being done twice for children nodes.

In GraphPanelMouseMotionListener, the code goes through the entire selection and does n.translate(dx, dy);.

However, the selection includes a parent node and all its children. However, the code for translate dynamically dispatches to AbstractNode.translate:

public void translate(double pDeltaX, double pDeltaY)
{
for(Node node : aChildren)
{
node.translate(pDeltaX, pDeltaY);
}
}
which goes through all the children (again!) so basically the error is caused by the children nodes being translated twice.

We won't be supporting this mode.

Includes Scenario Start, Activities, Decisions, Synchronization, etc. See .21 or 2.0.1 for the rest.

Make it more explicit that files can only be exported in .jpg and .png format. Deal with format individually with the optionalFilters as opposed to parsing the pipe-separated list of extensions. Simplify ExtensionFilter to only deal with a single extension.

This behavior is already implemented for CallNodes in the sequence diagams.

Steps to reproduce:

1. Create a diagram, save as testdata/Mydiagram...
2. Close it
3. Open the diagram with Recent Files
4. Save it using Save

It gets saved in the root directory, not in testdata, clearly the path part of the file name has been lost.

As part of this change:

• Refactor the toolbar to be a classic Swing toolbar
• Add labels to tools in the toolbar

A last thing to do before closing the milestone, @JoelChev and @EJBQ please delete your dead branches.

For some reason the discontinuity in the master branch corrupted branch 40. I'll just copy the changes over into a fresh branch from master.

Change the tool name and branding information everywhere, respecting the copyrights.

RedundantThrows and JUnitTestCase were removed as of Checkstyle 6.2.

It seems overkill to tag every note object with a color when the default is used for most of them. We can always add a global setting later if need be.

In State diagrams it should not be possible to add incoming edges to start nodes or outgoing edges from end nodes.

The welcome panel should appear whenever there are no diagram, and should support creating new diagrams or opening recent files. Probably a good idea to add this after we switch over to the tabbed panel.

There is an opportunity for polymorphism in that giant if and the switching on bent styles in general. Since we'll be playing with this code a lot when working on the routing algorithms, it will be nice if it's clean.

• Disables the menu if there are no recent files.
• Enable a maximum number of recent files (5).
• Add a file to the recent files menu when saving as.
• Test whether files exist before adding them to the recent files menu.
• Produce a better message when a file is not found.

One less command to undo

This is in both the current version and JetUML. It's possible to open a file, then open it again and get separate windows. This seems unintentional.

Using the control key it's possible to add to a list of selected elements. It should be possible to remove selected elements in the same way. In Violet 0.21 that is only possible for nodes so we'll replicate this behavior for now but ultimately this should be more consistent across nodes and edges. This should be based on a cleanup of the mouse handling in GraphPanel, which is a bit unprincipled right now.

Since the refactoring of the graph framework, properties appear in a strange order in the properties editor. This is because the properties editor is sensitive to the arbitrary order in which properties are discovered by the JavaBeans framework, and the fact that the priority property is not used by the comparator in the constructor of PropertySheet

The serialization of diagrams relies on the JavaBeans framework as opposed to binary serialization. It looks like we can get rid of all the binary serialization-related code.