Hi!
Using JGo 5.1 I experience the following issues, even in the demo:
Moving a manually resized (increased) subgraph around in a view leaves visual artifacts.
The handle tends to overlap the label instead of getting positioned right hand side of the handle.
In a manually resized (increased) subgraph the background is not pickable anymore with setPickableBackground(true).
Could you describe how you got that behavior? So far I have been unable to reproduce it.
I do notice that the TestSubGraph example class in Demo1 wasn’t designed to handle interactive resizing, since I see that the ports aren’t automatically repositioned as the Insets keep changing.
Hmmm, and the TestSubGraph2 example class wasn’t designed to handle interactive resizing either.
But for all of the subgraphs in Demo1, after setting Resizable to true and PickableBackground to true, I haven’t seen any problems with leaving visual artifacts or the handle overlapping the label or problems with picking in the background of the subgraph.
Have a look at this screenshot.
It seems, that only the “filled” part of the subgraph containing nodes repaints itself the right way during drags. Unfortunately I need a subgraph being able to be resized even without any content (nodes). I want the user to define an area (JGoSubgraph) and drop JGObjects on it that then get inserted into the subgraph.
The idea behind is that the subgraph is a representation of a certain process step within a flowchart.
OK, I get the problem with picking in the newly expanded margin, but I don’t get a problem with painting when dragging around the subgraph. What version are you using? 5.15 is the current version.
JGoSubGraph really wasn’t designed to be a “container” or a “box”. It was designed to be a grouping of nodes and links that had some “decoration” on it (the background and border) and Handle/Label/Port/CollapsedObject. So it doesn’t make sense for a JGoSubGraph to be manipulable without any “contents”. Whereas with a “box”, of course you can imagine having an empty box and being able to resize it.
That’s why JGoSubGraph doesn’t work well when there are no nodes in it. In retrospect we should have designed it to have a special child object (maybe the “border” – a JGoRoundRect?) which could act as the “box”. (I bet you only saw a problem with the relative positioning of the Handle and the Label when there were no nodes in the subgraph.)
You could implement this yourself, although it would be tedious, since it would need to act pretty much like the Port object where the Port is constantly being repositioned/resized as the JGoSubGraph is repositioned/resized. When I get a chance I’ll see if I can try this.
Indeed, with 5.15 the artifacts don’t show up and yes, the positioning problems came along with an empty SubGraph.
So it seems I have to code what I want myself and not based on JGoSubGraph. I just thought it would be a good starting point, but special needs and different special intentions for JGoSubGraph obviously don’t match well this time. ;)
Do you have any idea how to implement drag & drop capabilities for JGoObject?
Try the new BoxApp sample application that is included in 5.2 beta.
BoxArea is a like a greatly simplified version of JGoSubGraph, but uses a separate object (a JGoRoundedRect) as the border. Also the BoxView class extends JGoView by supporting dropping objects “into” a BoxArea.
I haven’t tested this with 5.15, so tell me if I accidentally included code that depends on newer features.
BoxApp runs fine with 5.15.
With BoxApp I experience the same issue as with my app: Linking ports per mouse does not work. But a look at the SubGraph related code in Demo1 may give some insight on how to get that to work. Maybe a little modification of the view…
I have to take a closer look at your DnD approach in BoxApp. I’ve been playing with the thought of modifying View#completeDrop but BoxView seems to handle that straighter forward in #fireUpdate.
What do you mean by “linking ports per mouse”?
Of course it didn’t need to be an override of JGoView.fireUpdate, since it is just a JGoViewListener. But since I had a subclass of JGoView anyway, it’s simpler to override a method than to define and register a listener.
In my test app and your BoxApp I can not click and drag a link from one simple node to the other, once both are part of BoxArea. It just seems to be unable to recognize the other port.
Ah, that’s because it’s not valid to draw a link from a port on a node to another (or the same) port on the same node, and because the ports think that they are part of the same node, the BoxArea.
That is one of the places where there is use of JGoSubGraph. One of the future features is that we will put another class into the hierarchy above JGoSubGraph but below JGoNode. All the code outside of JGoSubGraph that checks for JGoSubGraphs will check for that new class instead. That way programmers can define their own kinds of “subgraphs” with the implementation that they like, instead of having to use JGoSubGraph.
Try downloading the updated ZIP file. I got around the problem by defining a port class that overrides getParentNode to check for BoxArea instead of JGoSubGraph.
I just recognized that I will need Links to avoid nodes except of my custom node… The default behaviour makes some pretty funny linking…
EDIT:
Ah, just found out about JGoDocument#isAvoidable…
Okay, I got another related issue.
I overwrote JGoView#newLink and JGoView#reLink to make sure, that interactively created links in my subgraph are part of the subgraph and not of the document (B).
Now I wanted to check for a case in which a node added to the subgraph is linked with a node already part of the subgraph. In that case the link between them stays part of the document which is not what I want. (A1 - A4)
I overwrote #addCollection of my subgraph and within it I am able to detect this case, but adding the link to the subgraph for unknown reason does not do the trick.
/**
* @see com.nwoods.jgo.JGoArea#addCollection(java.util.ArrayList, boolean, com.nwoods.jgo.JGoLayer)
*/
public ArrayList addCollection(ArrayList coll, boolean reparentLinks, JGoLayer linksLayer) {
ArrayList al = super.addCollection(coll, reparentLinks, linksLayer);
ArrayList search = new ArrayList();
for (Iterator iter = al.iterator(); iter.hasNext(); ) {
JGoObject obj = (JGoObject)iter.next();
obj.setDragsNode(false);
obj.setAutoRescale(false);
if (obj instanceof JGoNode) {
JGoNode node = (JGoNode)obj;
search.clear();
ArrayList links = node.findAll(JGoNode.PartsLinks, search);
for (int i = 0; i < links.size(); i++) {
JGoLink link = (JGoLink)links.get(i);
JGoPort from = link.getFromPort();
JGoPort to = link.getToPort();
if (link != null && from != null && to != null) {
JGoObject commonParent = JGoObject.findCommonParent(from, to);
if (commonParent != null && commonParent instanceof ProcessStepNode) {
((ProcessStepNode)commonParent).addObjectAtTail(link);
}
}
}
}
}
layoutChildren(null);
return al;
} This is getting a bit too complicated for this forum. Perhaps it would be better if you sent e-mail.